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ABSTRACT 


This  paper  is  an  assessment  of  Department  of  Defense  (DoD)  and  service 
initiatives  to  ensure  joint  interoperability  of  Command,  Control,  Communications, 
Computers,  and  Intelligence  (C4I)  systems.  Using  a  consolidated  initiative  matrix, 
visions  and  actions  are  reviewed  to  identify  intent,  and  existing  documents  used  by  C4I 
system  planners,  designers,  and  developers  are  assessed  against  essential  system 
development  criteria,  required  baseline  actions,  to  achieve  interoperability.  Findings 
reveal  that  interoperability  development  guidance  and  tools  do  not  address  mission- 
specific  parameters  of  C4I  systems.  Not  all  C4I  systems  are  the  same.  Mission-specific 
requirements  dictate  whether  a  system  is  interoperable  or  not.  The  current 
interoperability  definition  is  quite  vague  for  mission-specific  systems,  and  existing  DoD 
and  service  initiatives  only  address  general  guidance  to  focus  system  development. 
Common  mission-specific  cases  are  provided  and  demonstrate  that  achieving 
interoperability  is  more  than  general  guidance  and  more  than  the  ability  to  pass  data  or 
information  through  seamless  interfaces  to  ensure  that  systems  are  functional. 
Interoperability  must  be  further  defined  by  analyzing  a  C4I  system’s  unique  mission. 
Finally,  to  guide  C4I  system  design,  a  framework  to  establish  quantifiable  thresholds  is 
developed  and  presented  using  existing  joint  doctrine. 
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EXECUTIVE  SUMMARY 


This  paper  is  an  assessment  of  Department  of  Defense  (DoD)  and  service 
initiatives  to  ensure  joint  interoperability  of  Command,  Control,  Communications, 
Computers,  and  Intelligence  (C4I)  systems.  Chapter  I  provides  a  starting  point  for 
readers  to  understand  DoD  and  service  initiatives.  This  chapter  consists  of  the  following 
sections:  purpose  of  thesis,  methodology,  scope  of  thesis,  definitions,  background,  and 
outline  of  chapters.  This  purpose  of  thesis  section  introduces  and  describes  this  paper’s 
topic  and  structure  for  the  reader,  and  the  research  methodology  section  gives  the  reader  a 
reference  perspective  for  the  research  and  analysis  conducted.  The  scope  of  thesis  section 
develops  the  boundaries  for  the  thesis  and  research.  The  definitions  and  background 
sections  list  Joint  Publication  1-02  definitions  that  directly  apply  and  establish  a  broad 
base  for  the  reader  to  understand  both  DoD  and  service  initiatives.  Within  the 
background  section,  overviews  of  the  C4I  for  the  Warrior  (C4IFTW)  concept,  DoD 
Technical  Architecture  for  Information  Management  (TAFIM),  DoD  interrelated 
architectures.  Joint  Technical  Architecture  (JTA),  and  levels  of  information  system  (IS) 
interoperability  are  provided. 

Chapter  II  addresses  the  US  Air  Force  perspective.  This  chapter  contains  the 
following  sections:  vision,  architectures,  capabilities  planning  and  architecture 
management,  and  conclusion.  The  vision  section  introduces  the  Air  Force’s  HORIZON 
concept.  The  architectures  section  is  subdivided  into  operational,  technical,  and  systems 
sections  to  identify  service  applications.  The  capabilities  planning  and  architecture 
management  section  describes  processes  established  to  support  the  development  of 
interoperable  systems;  lastly,  the  conclusion  section  recognizes  that  Air  Force  initiatives 
are  evolving. 

Chapter  III  reviews  Army  initiatives  and  is  divided  into  the  following  sections: 
vision,  architectures,  and  conclusion.  The  vision  section  summarizes  the  Army’s 
Enterprise  Strategy,  both  vision  and  implementation  plan.  The  architectures  section 
presents  the  Army’s  view  of  interrelated  architectures  to  support  the  development  of 


XIX 


interoperable  systems,  and  the  conclusion  section  acknowledges  that  Army  initiatives 
have  a  well-established  starting  base  and  are  continually  evolving. 

Chapter  IV  presents  the  US  Navy,  to  include  the  US  Marine  Corps.  This  chapter 
contains  vision,  architecture,  and  conclusion  sections.  The  vision  section  outlines  the 
Navy  and  Marine  Corps’  Copernicus  strategy,  and  the  architecture  section  presents  the 
application  of  recognized  DoD  architectures  used  to  achieve  joint  C4I  interoperability. 
Finally,  the  conclusion  section  identifies  that  Navy  and  Marine  Corps  interoperability 
initiatives  are  progressing. 

Chapters  I  -  IV  provide  a  broad  knowledge  base  of  both  DoD  and  service  actions 
to  achieve  joint  C4I  system  interoperability.  Chapter  V  builds  on  this  to  conduct  a 
consolidated  analysis  of  the  entire  action  spectrum.  Five  examples  are  presented  to 
illustrate  that  all  C4I  systems  are  not  the  same— each  system  has  its  own  unique  fimctional 
characteristics.  This  chapter  contains  the  following  sections:  consolidated  initiative 
summary,  similarities  and  differences,  positive  actions,  further  definitions,  mission- 
specific  examples,  and  summary.  The  consolidated  initiative  summary  section  presents  a 
vision,  action,  and  baseline  action  matrix  to  analyze  DoD  and  service  initiatives.  The 
similarities  and  differences  and  positive  actions  sections  provide  comments  based  on  the 
consolidated  analysis,  while  the  further  definition  section  identifies  areas  requiring 
additional  development.  Within  the  mission-specific  examples  section,  five  C4I  systems 
that  require  very  different  functional  parameters  to  support  mission  objectives  are 
presented.  Each  example  system  subsection  is  divided  into  scenario,  objective,  mission 
analysis,  and  conclusions,  and  examples  are  further  compared  using  a  mission-specific 
area  matrix.  The  summary  section  highlights  the  analysis  observations. 

Finally,  Chapter  VI  contains  conclusions,  recommendations,  and  further  areas  of 
research.  Building  on  the  previous  five  chapters,  this  chapter  identifies  critical  issues, 
provides  direction,  and  recommends  research  areas  requiring  analysis.  The  conclusions 
section  formalizes  identified  analysis  and  observations,  and  the  recommendations  section 
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presents  three  initiatives  to  enhance  the  development  of  joint  C4I  systems.  Lastly,  the 
further  research  section  identifies  four  areas  of  study  for  DoD  graduate  students. 
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I.  INTRODUCTION 


The  time  is  ripe  to  set  a  course  to  resolve  our  C4I  interoperability 
issues.  [Ref.  1] 

Colin  L.  Powell 

Chairman  of  the  Joint  Chiefs  of  Staff 

12  June  1992 

A.  PURPOSE  OF  THESIS 

To  paraphrase  General  Colin  L.  Powell  (Retired),  the  time  is  ripe  to  quantitatively 
define  interoperability.  Not  all  Command,  Control,  Communications,  Computer,  and 
Intelligence  (C4I)  systems  are  the  same.  Mission-specific  requirements  dictate  whether  a 
system  is  interoperable  or  not.  The  current  interoperability  definition  is  quite  vague  for 
mission-specific  C4I  systems,  and  existing  Department  of  Defense  (DoD)  and  service 
initiatives  only  address  general  guidance  to  focus  system  development.  Quantifiable 
parameters  must  be  articulated  for  all  systems  to  ensure  interoperability.  This  paper 
reviews  current  initiatives,  provides  an  assessment  of  these  initiatives,  presents  five 
common  examples  of  mission-specific  requirements,  and  outlines  a  framework  to  better 
quantify  system  parameters  for  planners,  designers,  and  developers. 

Chapter  I  provides  a  starting  point  for  readers  to  understand  DoD  and  service 
initiatives.  This  chapter  consists  of  the  following  sections:  purpose  of  thesis, 
methodology,  scope  of  thesis,  definitions,  background,  and  outline  of  chapters.  This 
section,  purpose  of  thesis,  introduces  and  describes  this  paper’s  topic  and  structure  for  the 
reader.  The  research  methodology  section  gives  the  reader  a  reference  perspective  for  the 
research  and  analysis  conducted.  The  scope  of  thesis  section  develops  the  boundaries  for 
the  thesis  and  research.  The  definitions  section  lists  Joint  Publication  1-02  definitions  that 
directly  apply,  and  the  background  section  establishes  a  broad  base  for  the  reader  to 
understand  both  DoD  and  service  initiatives.  Within  the  backgroxmd  section,  overviews 
of  the  C4I  for  the  Warrior  (C4IFTW)  concept,  DoD  Technical  Architecture  for 
Information  Management  (TAFIM),  DoD  interrelated  architectures.  Joint  Technical 
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Architecture  (JTA),  and  levels  of  information  system  (IS)  interoperability  are  provided. 
The  last  section  outlines  the  five  chapters  that  follow. 

Chapter  II  addresses  the  US  Air  Force  perspective.  Chapter  III  reviews  the  US 
Army,  and  Chapter  IV  presents  the  US  Navy,  to  include  the  US  Marine  Corps.  Chapter  V 
is  a  consolidated  analysis  with  examples  that  identify  the  need  for  mission-specific  C4I 
system  profiles,  and  quantifiable  interoperability  parameters.  Finally,  Chapter  VI  contains 
conclusions,  recommendations,  and  further  areas  of  research. 

B.  METHODOLOGY 

Using  a  consolidated  initiative  matrix,  both  DoD  and  service  visions  and  actions 
are  reviewed  to  identify  intent.  More  importantly,  existing  documents  used  by  C4I  system 
planners,  designers,  and  developers  are  assessed  against  essential  system  development 
criteria,  and  required  baseline  actions,  to  achieve  interoperability.  Findings  reveal  that 
interoperability  development  guidance  and  tools  do  not  address  mission-specific 
parameters  of  C4I  systems.  Common  mission-specific  cases  are  provided  and 
demonstrate  that  achieving  interoperability  is  more  than  general  guidance  and  more  than 
the  ability  to  pass  data  or  information  through  seamless  interfaces  to  ensure  that  systems 
are  functional.  Therefore,  interoperability  must  be  further  defined  by  analyzing  a  C4I 
system’s  imique  mission.  Finally,  to  guide  C4I  system  design,  a  framework  to  establish 
quantifiable  thresholds  is  developed  and  presented  using  existing  joint  doctrine. 

With  the  research  methodology  given,  the  following  questions  were  proposed: 

•  Is  the  current  definition  of  interoperability  adequate  to  ensure  the  seamless 
integration  of  C4I  systems? 

•  What  are  the  DoD  and  service  initiatives  to  ensure  C4I  system 
interoperability? 

•  Are  there  differences  in  initiatives?  If  so,  why  and  how  do  these  differences 
compare? 

•  Are  items,  such  as  system  interfaces  and  timing  requirements,  adequately 
articulated  through  existing  modeling  techniques? 
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Should  system  modeling  be  more  than  defining  data  elements? 

Should  there  be  interoperability  profiles  based  on  quantifiable  parameters? 


C.  SCOPE  OF  THESIS 

As  previously  mentioned,  this  paper  is  an  assessment  of  combined  DoD  and 
service  initiatives  to  ensure  joint  interoperability  of  C4I  systems.  Directives,  guidance, 
and  technical  architectures  have  been  developed  to  conform  to  service  initiatives  in  a 
positive  direction,  but  general  definition  is  not  enough.  The  detail  of  interoperability 
differs  for  each  mission-specific  case.  For  a  C4I  system  to  be  fimctional,  certain  system 
parametric  requirements  must  be  met.  With  the  vast  amount  of  participants,  standards, 
and  systems  involved,  solid  general  guidance  enhances  the  development  of  interoperable 
systems,  but  every  system  is  not  the  same. 

D.  DEFINITIONS 

Joint  Publication  1-02  defines  the  following  terms: 

1.  Architecture 

A  framework  or  structure  that  portrays  relationships  among  all  the  elements  of  the 
subject  force,  system,  or  activity.  [Ref  2] 

2.  Command,  Control,  Communications,  and  Computer  Systems 
Integrated  systems  of  doctrine,  procedures,  organizational  structures,  personnel, 

equipment,  facilities,  and  communications  designed  to  support  a  commander’s  exercise  of 
command  and  control  across  the  range  of  military  operations.  Also  called  C4  systems. 
[Ref  2] 

3.  Interoperability 

•  The  ability  of  systems,  units,  or  forces  to  provide  services  to  and  accept 
services  from  other  systems,  units,  or  forces  and  to  use  the  services  so 
exchanged  to  enable  them  to  operate  effectively  together. 

•  The  condition  achieved  among  communications-electronics  equipment  when 
information  or  services  can  be  exchanged  directly  and  satisfactorily  between 
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them  and/or  their  users.  The  degree  of  interoperability  should  be  defined  when 
referring  to  specific  cases.  [Ref  2] 

4.  Tactical  Command,  Control,  Communications,  and  Computer 

Systems 

The  facilities,  equipment,  communications,  procedures,  and  personnel  essential  to 
theater  level  and  below  commanders  for  planning,  directing,  and  controlling  operations  of 
assigned  and  attached  forces  pursuant  to  the  mission  assigned  and  which  provide(s)  for 
the  conveyance  and/or  exchange  of  data  and  information  from  one  person  or  force  to 
another.  [Ref  2] 

E.  BACKGROUND 

It  is  DoD  policy  to  acquire  quality  products  that  satisfy  the  needs  of  the 
operational  user  with  measurable  improvements  to  mission  accomplishment.  [Ref  3]  The 
application  of  this  concept  is  true  for  the  entire  acquisition  process  and  is  a  cornerstone 
for  interoperability.  The  threat  to  the  United  States  has  drastically  changed,  and  the  way 
the  services  fight  has  been  altered  to  meet  this  challenge.  No  longer  are  there  single 
service  operations.  Today,  a  multi-service  force  meets  mission  objectives  in  several 
operational  environments-the  battlespace,  To  better  support  and  improve  mission 
accomplishment,  the  Joint  Staff  developed  the  C4I  for  the  Warrior  (C4IFTW)  concept. 

1.  C4I  for  the  Warrior  (C4IFTW) 

The  imifying  theme  of  the  C4IFTW  concept  is  to  achieve  global  interoperability  that  will: 
allow  any  Warrior  to  perform  any  mission  at  any  time,  and  any  place;  be  responsive,  and 
reliable,  secure;  and  be  affordable.  [Ref  1] 

This  concept  addresses  joint  force  C4I  interoperability  issues  in  a  evolutionary 
manner.  Building  upon  lessons  learned  from  previous  conflicts,  rapidly  changing 
technology,  and  the  changing  national  security  strategy,  this  concept  provides  a  three 
phase  roadmap  to  achieve  total  interoperability  of  C4I  systems.  Figure  1  illustrates  the 
Joint  Task  Force  (JTF)  C41  objective.  The  phases  of  the  roadmap  are:  Quick  Fix  Phase, 
Mid-Term  Phase,  and  Objective  Phase.  [Ref.  1] 
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Figure  1.  Joint  Task  Force  C4I  Objective  [From  Ref.  1] 


The  focus  of  the  Quick  Fix  Phase  was  to  be  achieve  interoperability  of  existing 
systems.  [Ref.  1]  In  1993,  this  phase  was  considered  a  success  based  on  the  following 
actions:  translators  and  interpreters  were  developed  along  with  data  base  interoperability, 
C4I  requirements  and  architectures  were  synchronized,  and  a  solid  foundation  of  joint 
interoperability  policy  and  doctrine  was  established.  [Ref  4]  Items,  such  as  DoD 
Directive  4630.5,  DoD  Instruction  4630.8,  Joint  Publications  6-0  and  6-02,  joint  training 
exercises,  and  the  Joint  Warrior  Interoperability  Demonstrations  (JWIDs)  are  products  of 
this  phase. 

Within  the  current  Mid-Term  Phase,  total  interoperability  must  be  achieved  for 
new  C4I  systems  during  development,  testing,  acquisition,  and  implementation. 
Additionally,  this  includes  establishing  a  joint  wide  area  network  based  on  digital 


commonality — ^the  Global  Command  and  Control  System  (GCCS).  [Ref.  4]  This  phase  is 
continually  evolving  with  changing  technology,  new  directives,  and  updated  standards. 

Finally,  using  the  experience  gained  in  the  first  two  phases  and  advancing 
technologies,  the  Objective  Phase  addresses  optimizing  C4I  support  for  the  Warrior.  The 
objectives  are  to  create  a  multi-functional,  multimedia  terminal  fitted  to  the  Warrior’s 
manprint,  a  fully  integrated  tactical  picture  based  on  fused  information  from  the 
battlespace  and  an  integrated  global  infosphere.  [Ref  4] 

2.  DOD  Technical  Architecture  for  Information  Management  (TAFIM) 

The  Technical  Architecture  for  Information  Management  (TAFIM)  is  designed  to 
guide  the  development  of  the  DoD  infrastructure.  It  provides  the  services,  standards, 
design  concepts,  components,  and  configurations  to  guide  the  development  of  technical 
architectures.  The  TAFIM  promotes  interoperability  of  information  systems,  but  does  not 
address  mission-specific  applications/systems.  Within  the  DoD,  using  the  TAFIM  is 
mandatory.  If  everyone  follows  the  DoD  directive  to  use  it,  more  C4I  systems  will 
become  more  interoperable.  The  proper  application  of  the  TAFIM  is  expected  to:  [Ref.  5] 

•  Promote  integration,  interoperability,  modularity,  and  flexibility 

•  Guide  acquisition  and  reuse 

•  Speed  the  delivery  of  information  technology  with  lower  costs 

The  TAFIM  Version  2.0  is  divided  into  the  following  volumes:  Volume  1, 
Overview,  Volume  2,  Technical  Reference  Model,  a  conceptual  model  for  information 
system  services  and  their  interfaces;  Volume  3,  Architecture  Concepts  and  Design 
Guidance,  concepts  and  guidance  to  support  the  development  of  technical  architectures; 
Volume  4,  DoD  Standards-Based  Architecture  Planning  Guide,  a  standards-based 
architecture  planning  methodology;  Volume  5,  Support  Plan,  describes  how  to  use 
TAFIM  guidance  for  acquisition  (Draft);  Volume  6,  DoD  Global  Security  Architecture, 
common  DoD  security  requirements;  Volume  7,  Information  Technology  Standards 
Guidance,  DoD  profile  of  standards;  and  Volume  8,  DoD  Human  Computer  Interface 
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(HCI)  Style  Guide,  a  common  framework  for  HCI  design  and  implementation.  [Ref.  5] 
TAFIM,  Version  3.0  Draft,  is  currently  posted  for  review  on  the  world  wide  web 
(WWW). 

3.  DOD  Interrelated  Architectures 

With  the  rapid  growth  of  architectures  in  recent  years,  the  DoD  defined  an 
interrelated  set  of  architectures  to  support  the  development  of  interoperable  systems: 
Operational,  Technical,  and  Systems.  The  Operational  Architecture  describes  the  tasks, 
operational  elements,  and  information  flows  required  to  accomplish  or  support  a 
warfighter  function.  The  Technical  Architecture  is  the  minimal  set  of  rules  that  governs 
the  arrangement,  interaction,  and  interdependence  of  the  parts  or  elements  whose  purpose 
is  to  ensure  that  a  system  satisfies  a  specified  set  of  requirements.  The  Systems 
Architecture  is  the  descriptions,  including  graphics,  of  systems  and  interconnections 
providing  for  or  supporting  a  warfighting  functions.  Figure  2  illustrates  the  relationships 
of  these  architectures.  [Ref.  6] 
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Figure  2.  Relationships  of  Architectures  [From  Ref.  6] 

4.  Joint  Technical  Architecture  (JTA) 

On  12  March  1996,  the  Joint  Technical  Architecture  (JTA),  Version  0.5 
Preliminary  Draft,  was  posted  for  evaluation  on  the  WWW.  This  document  was 
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developed  by  a  working  group  using  the  Army’s  Technical  Architecture  (AT A)  as  a 
starting  point;  the  AT  A  will  be  covered  in  Chapter  III.  The  JTA  has  three  mutually 
supporting  objectives:  [Ref.  6] 

•  To  provide  the  foundation  for  a  seamless  flow  of  information  and 
interoperability  among  all  tactical,  strategic,  and  sustaining  base  systems  that 
produce,  use,  or  exchange  information  electronically. 

•  To  mandate  standards  and  provide  guidelines  for  system  development  and 
acquisition  which  will  significantly  reduce  cost,  development  time,  and 
fielding  time  for  improved  systems. 

•  To  influence  the  direction  of  the  information  industry's  technology 
development  by  stating  the  DoD's  direction  and  research  and  development 
investment  so  that  it  can  be  more  readily  leveraged  in  systems  within  DoD. 

Eventually,  the  JTA  will  apply  to  all  systems  that  produee,  use,  or  exchange 
information  electronically.  This  initial  version  is  focused  on  C4I  systems  and  their 
interfaces  with  other  entities,  such  as  weapon  systems,  sensors,  office  automation 
systems,  etc.,  to  support  interoperability.  Operational  requirements  developers  will  use 
the  JTA  to  guide  the  development  of  requirements  and  functional  descriptions.  System 
developers  will  use  the  JTA  to  ensure  that  new  and  upgraded  systems  meet  established 
interoperability  requirements,  and  system  integrators  will  use  this  document  to  facilitate 
the  integration  of  both  existing  and  new  systems. 

The  JTA  contains  the  following  seven  sections;  Overview,  Information 
Processing  Standards,  Information  Transfer  Standards,  Information  Modeling  and  Data 
Exchange  Standards,  Human-Computer  Interfaces,  Information  Systems  Security,  and 
Emerging  Standards.  [Ref  6] 

Section  4,  Information  Modeling  and  Data  Exchange  Standards,  identifies  the 
minimum  information  standards  applicable  to  information  modeling  and  exchange  of 
information  for  all  DoD  programs.  The  Integrated  Definition  (IDEE)  modeling  methods 
have  been  adopted  by  the  DoD  to  support  the  identification  of  information  and 
information  exchange  requirements  for  the  development  of  interoperable  systems.  Federal 
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Information  Processing  (FIPS)  Publication  183,  Integration  Definition  for  Function 
Modeling  (IDEFO),  is  used  to  guide  activity  modeling,  while  FIPS  Publication  184, 
Definition  for  Information  Modeling  (IDEFIX),  is  used  to  govern  data  modeling.  Using  a 
common  language,  IDEFO  activity  models  capture  an  organization’s  processes  at  the 
highest  logical  levels.  Processes  are  further  decomposed  into  lower  logical  levels  to 
uncover  supporting  processes.  [Ref.  6] 

The  DoD  created  the  Defense  Data  Dictionary  System  (DDDS)  to  provide  a  single 
authoritative  source  for  data  standards.  Managed  by  DISA,  the  DDDS,  a  DoD-wide 
central  data  base,  includes  standard  data  entities  and  elements  and  access  to  data  models. 
Also,  the  DDDS  is  used  to  collect  individual  data  standards  and  document  content  and 
format  for  data  elements.  An  objective  view  of  how  the  adopted  modeling  methods  and 
data  standards  will  support  the  development  of  interoperable  systems  is  depicted  in 
Figure  3. 
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Figure  3.  Objective  Information  Standards  Technical  Architecture  [From  Ref.  6] 
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5.  Levels  of  Information  System  (IS)  Interoperability 

In  1993,  DoD  services  and  agencies  realized  that  the  existing  interoperability 
definition  was  insufficient.  As  a  result,  a  simple  six-level  construct  was  developed  to 
describe  different  levels  of  interoperability.  Figure  4  provides  a  description  of  these  levels 
along  with  enabling  capabilities  for  each  level.  [Ref  7] 
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Figure  4.  Levels  of  Interoperability  (circa  1993)  [From  Ref.  7] 


In  April  1995,  the  Joint  Interoperability  Test  Center  (JITC)  expressed  an  interest 
in  pursuing  the  levels  construct  as  a  basis  for  joint  systems  certification,  and  recently,  the 
C4I  Surveillance  and  Reconnaissance  Integration  Task  Force  (C4ISR  ITF)  endorsed  the 
concept.  The  MITRE  Corporation  recently  updated  the  concept  to  integrate  the  planned 
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functions  of  the  Defense  Information  Infrastructure  (DII),  emerging  Internet  services,  and 
six  NATO  interoperability  levels.  Currently,  MITRE  is  coordinating  with  key  DoD 
organizations  for  levels  refinement.  [Ref.  7]  Figure  5  depicts  the  revised  levels  construct. 

The  revised  construct  contains  three  interoperability  categories;  transaction, 
service,  and  application.  The  transaction  category  addresses  the  ability  to  establish  a 
connection  between  discrete  systems  and  conduct  basic  exchanges  of  data.  The  service 
category  addresses  the  interoperability  effects  of:  distributed  computing  services, 
community  leveraging  of  common  solutions,  establishing  standard  system  and  user 
interfaces,  and  exchanging  more  complex  data  types.  Finally,  the  application  category 
addresses  the  establishment  of  the  C4ISR  IS  objective  based  on  C4IFTW  vision.  [Ref.  7] 
The  categories  are  further  subdivided  into  levels  as  annotated  in  Figure  5. 
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Figure  5.  Revised  IS  Levels  Construct  [From  Ref.  7] 
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F. 


OUTLINE  OF  CHAPTERS 


1.  Chapter  II  -  United  States  Air  Force 

This  chapter  summarizes  the  US  Air  Force’s  HORIZON  vision  and  supporting 
actions  to  achieve  interoperability.  The  service  perspective  and  existing  tools  in  use  are 
described  to  outline  the  Air  Force’s  perspective  to  develop  interoperable  systems. 

2.  Chapter  III  -  United  States  Army 

The  US  Army’s  Enterprise  vision  and  implementation  plan  are  presented  along 
with  the  established  processes  to  achieve  the  development  of  interoperable  systems. 

3.  Chapter  IV  -  United  States  Navy  and  Marine  Corps 

The  Copernicus  vision  and  Marine  Corps  Technical  Architecture  are  discussed  to 
outline  the  US  Navy  and  Marine  Corps’  actions  to  ensure  the  development  of 
interoperable  C4I  systems. 

4.  Chapter  V  -  Analysis 

Chapter  V  provides  a  consolidated  view  of  the  DoD  and  service  initiatives  to 
address  interoperability  of  C4I  systems.  Documented  actions  are  compared  and 
consolidated  within  an  analytical  matrix  format.  Mission-specific  interoperability  profiles 
are  presented  to  clearly  identify  that  individual  system  requirements  may  require  different 
design  parameters  for  systems  to  function. 

5.  Chapter  VI  -  Conclusions  and  Recommendations 

This  chapter  contains  conclusions,  recommendations,  and  further  research  areas 
based  on  the  Chapter  V  analysis.  A  framework  to  quantify  C4I  system  parameters  is 
outlined. 
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II.  UNITED  STATES  AIR  FORCE 


History  has  shown  that  the  side  that  effectively  analyzes,  decides,  and 
acts  the  fastest  will  prevail  in  any  conflict.  We  can  and  must  make 
optimum  use  of  information  technology  to  operate  inside  any  opponent’s 
decision  cycle.  [Ref.  8] 

Ronald  R.  Fogleman 
USAF  Chief  of  Staff 
August  1995 

A.  INTRODUCTION 

With  the  world  changing,  information  is  becoming  a  new  center  of  gravity — a 
strategic  asset,  inviting  attack  and  requiring  protection.  Before,  warfare  was  only 
considered  in  air,  land,  sea,  and  space  operational  environments,  but  the  Air  Force  has 
now  recognized  information  as  a  fifth  operational  environment.  Information  dominance  is 
crucial  to  military  success  across  the  spectrum  of  conflict.  [Ref  8] 

Chapter  II  contains  the  following  sections:  vision,  architectures,  capabilities 
planning  and  architecture  management,  and  conclusion.  The  vision  section  introduces  the 
Air  Force’s  HORIZON  concept.  The  architecture  section  is  subdivided  into  operational, 
technical,  and  systems  sections  to  identify  service  applications.  The  capabilities  planning 
and  architecture  management  section  describes  processes  established  to  support  the 
development  of  interoperable  systems;  lastly,  the  conclusion  section  recognizes  that  Air 
Force  initiatives  are  evolving. 

B.  VISION 

In  1993,  realizing  the  importance  of  information  technology,  the  US  Air  Force 
developed  the  HORIZON  concept  as  an  extension  of  the  Joint  Staffs  C4I  for  the  Warrior 
(C4IFTW)  construct  for  joint  interoperability.  This  concept  focused  on  information 
architectures  to  develop  an  integrated  and  responsive  global  infosphere  that  supports  both 
Global  Reach  and  Global  Power  objectives.  For  the  first  time,  the  Air  Force  sought  to 
define  a  path  to  a  service-wide  architecture  of  C4I  systems.  This  past  year,  the  Air  Force 
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updated  their  vision  with  C4I  HORIZON  ’95.  This  document  expands  the  previous 
HORIZON  vision  by  establishing  2r‘  century  information  infrastructure  objectives  and 
plans  for  rapid  integration  of  evolving  technology  within  the  current  and  future 
infrastructure.  C41  HORIZON  ’95  contains  the  visions  for  achieving  information 
superiority  and  leading  the  US  Air  Force  into  the  information  age.  This  updated  edition 
defines  a  planning  perspective  and  evolutionary  path  for  information  systems  and  the 
application  of  information  technology  across  the  spectrum  of  Air  Force  operations.  [Ref 
8] 

C.  ARCHITECTURES 

With  the  vision  to  seamlessly  integrate  information  systems,  the  Air  Force  created 
a  framework  to  coordinate  and  integrate  related  major  command  (MAJCOM)  information 
architectures.  As  defined  by  the  Defense  Science  Board,  and  previously  mentioned  in 
Chapter  I,  background  section,  the  Air  Force  adopted  the  three  broad  constructs  for 
information  requirements  and  planning:  operational,  technical,  and  system  architectures. 
[Ref  8] 

1.  Operational 

The  Air  Force  models  operational  architectures  that  represent  a  description  of  the 
tasks,  operational  elements,  and  information  flows  required  to  accomplish  or  support  a 
warfighting  function.  [Ref  8] 

2.  Technical 

The  Air  Force  is  currently  drafting  a  service  technical  architecture  that  will  be  released 
for  review  on  the  WWW  in  May  or  June  1996.  The  architecture  will  reflect  a  minimal  set 
of  rules  governing  the  arrangement,  interaction,  and  interdependence  of  the  parts  or 
elements  of  a  system.  [Ref  8]  Until  the  service  technical  architecture  is  finalized,  C41 
system  designers  are  required  to  use  established  technical  reference  codes  (TRCs).  To 
assist  C4  systems  designers  during  acquisition  and  modification  of  C4I  systems,  the 
USAF  created  TRCs.  TRCs  are  a  set  of  reference  documents  containing  policy, 
directives,  transition  guidance  and  standards  that  designers  can  easily  access  using 
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various  web  browsers  on  the  WWW.  They  assist  planners  with  standardizing  systems  to 
ensure  interoperability  of  future  developments.  TRCs  bring  together  government  and 
non-government  standards  and  Air  Force  and  DoD  policies  and  guidance  for  C4I  systems 
and  system  components  of  both  fixed  and  deployed  systems.  TRCs  are  based  on  the 
TAFIM,  and  they  articulate  standards  to  ensure  interoperability.  Through  the  process  of 
combining  standards  and  interoperability  related  documents,  a  detailed  profile  is  created 
for  almost  every  conceivable  system;  therefore,  solid  guidance  for  interoperability  is 
provided.  [Ref  9] 

There  are  two  types  of  TRCs:  Component  and  Service.  Information  for 
Component  TRCs  is  organized  by  categories  of  system  components,  and  information  for 
Service  TRCs  is  organized  by  user  C4I  system  capability.  Usually,  Component  TRCs  are 
used  for  smaller  acquisitions  and  piece-part  buys,  while  Service  TRCs  address  larger 
acquisitions  and  procurement  of  a  C4I  user  requirement  capability.  [Ref  9]  Table  1 
outlines  the  orientations  of  both  TRC  types. 


Service  TRCs  Tend  to  Address: 

Component  TRCs  Tend  to  Address: 

Larger  Acquisitions 

Smaller  Acquisitions 

Entire  C4I  Systems 

Individual  Components  of  C4I  Systems 

Broad-Based  Ideas 

Commercial-Off-The-Shelf  Solutions 

Abstract  Interoperability  Guidance 

Interoperability  Guidance  For  Specific  Components 

Concerns  For  System  Designs 

Strategies  For  Meeting  The  Specifications  of 
System  Design 

Table  1.  Orientation  of  Service  and  Component  TRCs  [From  Ref.  9] 


As  users  access  TRCs  for  information,  they  start  with  top  level  requirements  and 
move  down  the  tree  structure  depicted  in  Figure  6.  Depending  on  the  level  of  detail  and 
information  required,  users  may  have  to  reference  one  or  more  sub-levels  to  collect  all 
necessary  standards.  This  may  require  access  to  both  Component  and  Service  TRCs. 
[Ref  9] 
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TOP  Level 
TRC 

AFM33425 


CortipDnents 


Services 


C5.0 
Applications 
Software 


Cl.l  MimCoorpiteis 
Cl  2  Mamfiame  Corr^uters 
Cl 3  Works tatioais 

C  1.3.1  Personal  Conpiters 
C  1.3.2  Engiiieemig 
Works  fe-tions 
Cl. 4  Operating  Systems 
C13  Servers 

C2.1  Irpit  Devices 
C22  Outpiit Devices 
C23  Mass  Storage  Devices 
C2.4  Network  Interface  Devices 


C3.1  Vodce 
C32  Image 
C33  Video 
C3.4  Data 

C4.1  Data  Networks 

C4.1.1  Network  biterface  Cards 
C4.1.2  Transceivers 
C4.1.3  nihs 
C4.1.4  Repeaters 
C4.1.5  Biidges 
C4.1.6  Routers 

C4.1.7  LAN  Encryption Etevices 
C4,1.8  Ntwrk  Operating  System 
C4.1.9  Network  Management 
SystemCoftware 
C42  Telecamrrwnicatioris 

C4.2.1  Switching  System 
C4.2.2  CustomerPremiseEqpmt 
C4.2.3  TrarisnrdssianTeimnal 
Eqpaipment 

C4.2.4  Span  Line  Equipment 
C4.2.5  Cable  Distribution 
C43  Radio 

C4.3.1  Land  Mobile  Radios 
C4.3.2  CeUilar  Radios 
C4.3.3  UHF/VHF/HF  Radios 

C5.1  Office  Automadion 
C52  Software  Development 


5 1 . 1  Target  Cap  A  iHties  DMS 

51.2  AUTODIN  Capabilities 


52.1  Switched  Services 

52.2  Cellular  Services 

52.3  Land  Mobile  Radio  ServMes 

53.1  Imagery  Services 

53.2  Video  Services 

53.3  Facsimile  Services 


54.1  Operating  System  Services 

54.2  Distributed  Services 

54.3  Data  Management  Services 

54.4  System  Management  Services 

54.5  SofWaje Developrnent Services 

54.6  User  Interfkie  Services 

54.7  Multi-Media S ervices 

54.8  Info  Interchange  Services 

54.9  Security  Services 

54.10  Graphics  Services 


S  5. 1  Applications  Support  S  ervices 

55.2  InteirMetworking Services 

55.3  Networking  Technologies 

55.4  Application  Program  Interface 
Services 

56.1  Network  Management  Services 

56.2  System  Management  Services 


Figure  6.  TRC  Tree  Structure  [After  Ref.  9] 
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3.  Systems 

The  Air  Force  further  defines  their  C4I  systems  through  system  architectures. 
These  architectures  provide  a  description,  including  graphics,  of  the  systems  and 
interconnections  providing  for  or  supporting  a  warfighter  function.  [Ref  8] 

D.  CAPABILITIES  PLANNING  AND  ARCHITECTURE  MANAGEMENT 

The  C4I  capabilities  planning  process.  Figure  7,  is  designed  to  link  operational 
needs  to  architectures,  and  provide  a  top-level,  enterprise-wide  view,  so  systems 
architects  may  design  fully  integrated  joint  C4I  systems.  [Ref  8]  Automated  tools  are 
used  to  display,  analyze,  and  manage  key  architecture  elements  and  interconnections 
within  the  service  and  external  entities,  such  as  other  DoD  organizations  and  coalition 
forces.  [Ref.  8] 


MAP 

FAP 

■ly 

IMTEGRATED 
JOINT  C4I 
SYSTEM 


Figure  7.  C4I  Capabilities  Planning  Process  [From  Ref.  10] 


The  Air  Force  is  institutionalizing  C4I  Codes,  Permits,  and  Inspections  (CPI)  to 
ensure  that  C4I  capabilities  and  architectures  are  used  throughout  the  requirements, 
acquisition,  and  testing  processes.  This  guides  system  acquisition  to  ensure  developers 
follow  established  building  codes.  [Ref  8] 
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Figure  8  illustrates  the  HORIZON  architecture  management  process.  Within  this 
process,  a  database  is  used  to  develop  service-wide  architectures.  Eventually,  the  database 
will  be  automatically  updated  from  MAJCOM  architectural  activity  databases  and  tools. 
Emerging  modeling  and  simulation  techniques  are  used  to  facilitate  architecture 
development.  [Ref.  8] 


AF  Mission  and 
Support  Areas 


Database 


Discovered  Issues 

-  Examination 

-  Analysis 


Air  Force  C4I 

Architecture  Steering  Group 


Known  Issues 
-  Field  Experience 
‘  Test 

■  Other  Initiatives 


Issues 

-  Characterize 

-  Prioritize 

-  Resolve 

-  Track 
“Verify 

Issues 

Resolution 

Figure  8.  HORIZON  Architecture  Management  Process  [From  Ref.  8] 


E.  CONCLUSION 

The  Air  Force’s  strategy  to  ensure  interoperability  is  continuously  evolving.  Many 
actions  outlined  within  the  HORIZON  vision  have  taken  place,  while  others  are  currently 
being  developed  and  refined.  To  better  guide  Air  Force  personnel  through  C4I  capability 
development,  paperless  information  sharing  is  established  via  the  WWW. 
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III.  UNITED  STATES  ARMY 


As  we  know,  the  challenges  of  joint  interoperability  are  great.  The 
Enterprise  Strategy  is  the  framework  by  which  we  will  meet  and  conquer 
these  challenges.  It  is  a  vision  for  present  and  future  information  support 
for  our  Total  Army.  [Ref  11] 

Gordon  R.  Sullivan 
General,  United  States  Army 
Chief  of  Staff 
20  July  1993 

A.  INTRODUCTION 

Recent  history  and  changes  in  the  world  have  altered  the  focus  for  today’s  armed 
forces.  Today’s  threats  are  less  defined  and  pose  unique  challenges  for  warfighters  to 
counter.  From  the  Army’s  view,  countering  tomorrow’s  threats  requires  “Winning  the 
Battlefield  Information  War.”[Ref.  11] 

Chapter  III  is  divided  into  the  following  sections;  vision,  architectures,  and 
conclusion.  The  vision  section  summarizes  the  Army’s  Enterprise  Strategy,  both  vision 
and  implementation  plan.  The  architectures  section  presents  the  Army’s  view  of 
interrelated  architectures  to  support  the  development  of  interoperable  systems,  and  the 
conclusion  section  acknowledges  that  Army  initiatives  have  a  well-established  starting 
base  and  are  continually  evolving. 

B.  VISION 

As  stated  in  Army  Enterprise  Strategy:  The  Vision,  the  purpose  of  the  Army 
Enterprise  Strategy  is  to  support  US  Army  warfighters  into  the  21st  century.  The  strategy 
is  designed  to:  unify  the  C4I  community  toward  a  common  goal;  establish  a  structure  to 
guide  the  system  development  process;  develop  economic,  functional,  and  technical 
guidelines  and  criteria  to  aid  resource  managers  in  making  C4I  system  assessments;  and 
provide  a  broad  systems  perspective  across  DoD.  [Ref.  11] 

As  previously  mentioned,  for  the  Army  to  counter  today’s  threats,  warfighters 
must  “Win  the  Battlefield  Information  War.”  Through  the  exploitation  of  information 
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technology,  this  goal  is  achievable.  That  is  why  the  Enterprise  Strategy  focuses  on 
identifying,  supplying,  and  implementing  sophisticated  information  and  other  C4I 
technologies  in  support  of  the  warfighter.  [Ref  1 1  ] 

The  Enterprise  Strategy  contains  both  a  vision  and  an  implementation  plan.  The 
vision  introduces  and  explains  ten  principles  needed  to  ensure  the  warfighter  has 
information  superiority  over  any  adversary.  The  following  principles  are  exclusively 
taken  from  the  Enterprise  vision  document:  [Ref  1 1] 

•  Focus  on  the  Warfighter  -  Provide  the  Warfighter  C4I  systems  that  meet 
validated  needs. 

•  Ensure  Joint  Interoperability  -  Provide  the  Warfighter  C4I  systems  that 
interoperate  in  Joint  and  Combined  operations. 

•  Capitalize  on  Space-Based  Assets  -  Provide  the  Warfighter  assured  access  to 
mission  essential  military  and  commercial  space-based  systems  that  support 
the  Force  Projection  Army  across  the  entire  operational  continuum. 

•  Digitize  the  Battlefield  -  Provide  the  Warfighter  an  integrated  digital 
information  network  that  supports  warfighting  systems  and  assures  C2 
decision-cycle  superiority. 

•  Modernize  Power  Projection  Platforms  -  Provide  the  Warfighter  a  modem 
power  projection  platform  to  support  peacetime  operations,  mobilization, 
force  projection,  split-base  operations,  and  redeployment. 

•  Optimize  the  Information  Technology  Environment  -  Provide  the  Warfighter 
with  more  efficient  information  support  for  combat  and  peacetime  operations. 

•  Implement  Multi-Level  Security  -  Provide  the  Warfighter  the  ability  to  access 
and  exchange  information  at  needed  levels  of  classification  using  a  single  C4I 
system. 

•  Acquire  Integrated  Systems  Using  Commercial  Technology  -  Provide  the 
Warfighter  C4I  capabilities  that  leverage  commercial  technology. 

•  Ensure  Spectrum  Supremacy  -  Provide  the  Warfighter  electromagnetic 
spectrum  supremacy  in  order  to  maximize  the  benefits  of  maneuver  and  tempo 
in  conjunction  with  firepower. 
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•  Exploit  Modeling  and  Simulation  -  Provide  the  Warfighter  with  cost  effective 
training,  testing,  and  rapid  prototyping  through  state-of-the-art  modeling  and 
simulation. 

As  indicated  by  the  principles,  the  present  and  future  ways  the  Army  intends  to 
conduct  military  operations  is  going  through  a  dramatic  change.  The  operational 
environment  is  no  longer  a  localized  area  or  geographically  contained.  The  intelligent 
application  of  Information  Age  technology  will  equip  warfighters  with  the  necessary 
tools  to  access  critical  information  and  enhance  coordination  for  the  successful  execution 
of  joint  or  combined  operations. 

Based  on  the  sound  principles  established  within  the  vision,  the  implementation 
plan  provides  an  assessment  of  existing  systems,  an  investment  strategy  or  blueprint  for 
the  future,  and  an  action  plan  to  implement  the  strategy.  Specific  tasks  are  identified  and 
responsibilities  are  assigned  to  focus  a  unified  effort.  [Ref  12] 

C.  ARCHITECTURES 

Due  to  the  rapid  growth  of  architectures  within  the  C4I  and  information  system 
communities  in  recent  years,  the  Army  Science  Board  (ASB)  conducted  a  study  in  the 
Summer  of  1994.  As  a  result,  an  interrelated  set  of  architectures  was  defined: 
Operational,  Systems,  and  Technical.  As  mentioned  in  Chapter  I,  these  concepts  were 
adopted  by  the  DoD  as  well  as  the  Army  Enterprise  Strategy.  [Ref  13]  Figure  9 
illustrates  the  relationship  among  these  architectures.  This  figure  along  with  the 
architecture  definitions  differ  slightly  from  Figure  2,  Relationships  of  Architectures,  and 
definitions  presented  in  Chapter  I;  the  Army  Technical  Architecture  (ATA)  was  the 
starting  point  for  the  JTA  and  has  been  further  developed  with  other  service  documents 
by  a  multi-service  committee  to  support  the  joint  community.  [Ref  6]  The  following 
architecture  definitions  were  exclusively  taken  from  the  ATA. 

1.  Operational 

The  Operational  Architecture,  often  graphical,  describes  force  elements  and 
information  exchange  requirements  between  these  elements.  [Ref  13]  The  Army  is 
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currently  developing  these  architectures  based  on  the  Force  XXI  initiative,  a 
reconceptualization  and  redesign  of  the  force  at  all  echelons.  The  application  of 
advanced  technology  on  today’s  modem  battlefield  is  altering  these  architectures. 


>-  Technical  Architecture  is  the 
’'building  code^  upon  which 
systems  are 


SamessralesMi.- 

>  System  Architecture  is  a  physical 
implementation  of  the  OA,  the 
layout  and  relationship  of 
computers  and  communications 


Figure  9.  Different  Architectures  [From  Ref.  13] 


2.  Technical 

As  defined  in  the  ATA,  the  Technical  Architecture  is  the  minimal  set  of  rules  that 
governs  the  arrangement,  interaction,  and  interdependence  of  the  parts  or  elements  that 
together  may  be  used  to  form  an  information  system.  The  ATA  is  recognized  as  a  set  of 
“building  codes”  and  applies  to  all  systems  that  produce,  use,  or  exchange  information 
electronically.  Released  30  January  1996,  Version  4.0  is  based  on  the  TAFIM,  DoD 
Directive  8320-series  governing  standardization,  and  the  Army’s  initiatives  to  streamline 
the  acquisition  process.  Articulated  in  the  ATA  are  three  mutually  supporting  objectives; 
[Ref.  13] 


•  To  provide  the  foundation  for  seamless  flow  of  information  and 
interoperability  among  all  tactical,  strategic,  and  sustaining  base  systems  that 
produce,  use,  or  exchange  information  electronically. 
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•  To  provide  guidelines  and  standards  for  system  development  and  acquisition 
that  will  dramatically  reduce  cost,  development  time,  and  fielding  time  for 
improved  systems. 

•  To  influence  the  direction  of  the  information  industry’s  technology 
development  and  research  and  development  investment  so  that  it  can  be  more 
readily  leveraged  in  Army  systems. 

The  ATA  consists  of  the  following  six  sections:  Overview,  Information 
Processing  Standards,  Information  Modeling  and  Data  Exchange  Standards,  Human- 
Computer  Interfaces,  and  Information  Security. 

3.  System 

The  Systems  Architecture  is  the  description,  including  graphics,  of  the  systems 
solution  used  to  satisfy  the  warfighter’s  Operational  Architecture  requirement. 

D.  CONCLUSION 

The  Army  Enterprise  Strategy  starts  with  sound  principles  to  establish  a  tightly 
focused  vision  for  the  Army  C4I  community.  By  using  a  process-oriented  view  for  joint 
C4I  systems  development,  the  Army  will  achieve  intended  objectives  outlined  within  the 
Enterprise  Strategy.  As  with  all  initiatives  concerning  interoperability  within  DoD,  the 
process  is  evolving. 
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IV.  UNITED  STATES  NAVY  AND  MARINE  CORPS 


We  have  to  be  able  to  adapt  quickly  to  changing  technology  to  fight 
and  win  wars  in  the  Information  Age.  It  is  clear  that  information  has 
become  a  major  factor  in  warfare  and  will  grow  in  importance  in  the  next 
century.  [Ref.  14] 

Admiral  J.  M.  Boorda,  USN 
Chief  of  Naval  Operations 
February  1996 

A.  INTRODUCTION 

As  the  Information  Age  emerged,  the  US  Navy  recognized  the  potential  of  using 
information  as  a  warfighting  tool.  In  response,  the  Navy  developed  a  strategy  to  make 
C4I  systems  more  responsive  for  the  warfighter.  For  modern  warfare  in  the  joint 
battlespace,  the  requirement  for  information  dominance  has  become  essential. 
Information-based  warfare  allows  warfighters  to  increase  the  operational  tempo  of  battle 
by  exploiting  advanced  weapons  technology.  [Ref  14] 

This  chapter  contains  vision,  architecture,  and  conclusion  sections.  The  vision 
section  outlines  the  Navy  and  Marine  Corps’  Copernicus  strategy,  and  the  architecture 
section  presents  the  application  of  recognized  DoD  architectures  used  to  achieve  joint  C4I 
interoperability.  Finally,  the  conclusion  section  identifies  that  Navy  and  Marine  Corps 
interoperability  initiatives  are  progressing. 

B.  VISION 

Copernicus  provides  a  focus  for  the  Navy  and  Marine  Corps  to  make  C4I  systems 
more  responsive  to  the  warfighter,  to  field  C4I  systems  more  quickly,  to  capitalize  on  the 
advances  of  technology,  and  to  shape  doctrine  with  these  changes.  In  1992,  the  Navy  and 
Marine  Corps  team  published  “...From  the  Sea,  ”  and  along  with  Copernicus,  these 
documents  reflect  the  shift  from  a  maritime,  open-ocean  warfighting  environment  to  joint 
operations  in  the  littoral.  Copernicus  is  designed  as  a  user-centered  C4I  information 
management  architecture;  this  provides  a  framework  for  capturing  technological  change. 
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[Ref.  14]  Warfighters  are  supported  at  all  levels:  watchstander,  shore  commanders, 
Composite  Warfare  Commanders  (CWC),  and  Commander  Joint  Task  Force  (CJTF). 

Exclusively  defined  in  Copernicus... Forward,  Copernicus  contains  the  following 
five  essential  elements  that  provide  architectural  oversight  to  leverage  the  C4I 
infrastructure  effectively  and  enhance  the  C4I  operational  perspective.  [Ref  14] 


•  Seamlessly  blend,  through  common  applications  in  one  workstation,  critical 
tactical,  operational  and  administrative  data  to  the  warfighter,  thus  allowing 
tactical  objectives  to  drive  operations. 

•  Assimilate  required  information  rapidly  through  standardized  data  formats, 
permitting  operational  commanders  and  users  to  "pull"  desired  information  to 
accomplish  tasks.  A  two-way  intelligent  "push"  capability  supplements  user- 
pull  when  required  and  prevents  information  overload. 

•  Provide  information  using  integrated  data  formats  in  a  multimedia 
environment  where  form  fits  function  (i.e.,  voice,  video,  imagery,  and  tactical 
data  at  high  speeds). 

•  Provide  a  common  operating  environment  (COE)  that  standardizes 
workstations  for  the  operator.  Workstation  and  user  interface  standardization 
permits  greater  operator  proficiency  while  reducing  training  requirements. 

•  Use  common  building  blocks  for  modular  and  standardized  hardware  design, 
which  permit  upgrades  and  additions  to  the  architecture  in  an  expeditious 
manner. 

Copernicus,  a  framework  of  five  interactive  pillars,  links  command  and  control 
processes  at  all  echelons  of  command.  The  pillars  include:  Global  Information  Exchange 
System  (GLOBIXS),  a  system  that  supports  commanders  through  access  to  a  series  of 
wide  area  Defense  Communications  System  (DCS)  networks;  CINC  Command  Complex 
(CCC),  a  primary  gateway  for  communications  and  information  flow  from  GLOBIXS  to 
deployed  forces  via  Tactical  Data  Information  Exchange  System  (TADIXS);  TADIXS, 
tactical  networks  connecting  to  the  CCCs  with  the  Tactical  Command  Centers  (TCCs); 
TCC,  a  forward  deployed  command  center,  ashore  or  afloat,  that  disseminates 
information  to  the  warfighter;  and  Battlecube  Information  Exchange  System  (BCIXS),  a 
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system  that  supports  the  battlecube  in  which  tactical  forces  operate.  [Ref  14]  Figure  10 
depicts  the  pillars  of  Copernicus. 


ASHORE  AFLOAT  TACTICAL 

INFORMATION  MANAGEMENT  INFORMATION  MANAGEMENT  INFORMATION  MANAGEMENT 

Figure  10.  Pillars  of  Copernicus  [From  Ref.  14] 


Copernicus  provides  four  essential  C4I  functions:  common  tactical  picture  (CTP), 
connectivity,  sensor-to-shooter,  and  information  warfare  (IW).  The  CTP  is  the 
information  from  sensors  to  the  shooter  that  allows  the  tactical  commander  to  understand 
the  battlespace,  and  connectivity  links  communications  nodes  to  implement  the  sensor-to- 
shooter  construct.  This  construct  focuses  on  the  process  of  putting  the  weapon  on  target. 
The  migration  of  the  decision-making  process  from  upper  echelons  down  to  the  tactical 
commander,  or  shooter,  provides  a  true  sensor-to-shooter  environment.  As  illustrated  in 
Figure  11,  the  span  of  control  compresses  under  the  sensor-to-shooter  construct.  Finally, 
information  warfare  (IW)  is  any  action  to  confuse  or  destroy  the  enemy’s  information 


and/or  information  systems  while  leveraging  and  protecting  friendly  information  and/or 
information  systems  to  achieve  information  dominance.  [Ref.  14] 
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Figure  11.  Span  of  Control  [From  Ref.  14] 


C.  ARCHITECTURES 

As  defined  by  the  Defense  Science  Board,  and  previously  mentioned  in  Chapter  I, 
background  section,  the  Navy  adopted  the  three  broad  constructs  for  information 
requirements  and  planning:  operational,  technical,  and  system  architectures. 

1.  Operational 

The  Navy  and  Marine  model  operational  architectures  that  represent  a  description 
of  the  tasks,  operational  elements,  and  information  flows  required  to  accomplish  or 
support  a  warfighting  function. 
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2.  Technical 

The  Navy  does  not  have  a  technical  architecture,  but  expects  to  fully  embrace  the 
JTA  as  the  draft  becomes  final.  Currently,  the  TAFIM,  supplemented  with  Naval 
publications,  is  used  to  guide  system  development.  For  example,  the  Naval  Warfare 
Tactical  Database  (NWTDB)  Standards  Manual  provides  data  element  formats  and  inter¬ 
system  database  exchange  structures  for  system  developers,  database  producers,  and 
operational  users.  It  contains  administrative  information  needed  to  integrate  standards 
into  existing  systems,  data  models,  data  sets,  and  data  elements  that  support  the  evolving 
DoD  standards.  [Ref  15] 

Figure  12  is  the  Navy’s  objective  C4I  database  architecture.  This  shows  a 
common  interface  language  or  data  transfer  structure  that  is  required  to  support  common 
processing  in  an  open  systems  environment.  The  database  architecture  is  composed  of 
standardized  data  elements,  which  facilitate  the  exchange  of  data  by  automated  systems; 
normalized  logical  structure,  which  provides  a  standard  for  human  and  machine  to  relate 
and  exchange  data;  and  designated  sources,  for  the  production  of  reference  data.  [Ref.  1 5] 

In  October  1995,  the  Marine  Corps  published  a  technical  architecture  that  applies 
to  all  Marine  Corps  programs  for  Command  and  Control  (C2)  systems.  This  document 
provides  a  minimal  set  of  rules  for  system  development  and  is  designed  to  ensure 
interoperability  among  operating  forces,  the  Marine  Corps  supporting  establishment,  and 
joint  C2  systems.  The  architecture  leverages  commercial  technology  and  defines  Marine 
Corps  specific  standards  where  joint  standards  do  not  exist.  As  with  all  interoperability 
documents,  this  one  is  continually  evolving  and  future  versions  will  reflect  changes  in 
Navy  and  Marine  Corps  efforts  and  interoperability  requirements  with  other  DoD 
agencies.  [Ref.  16] 

This  Marine  Corps  Technical  Architecture  (MCTA)  is  divided  into  the  following 
sections;  Overview,  Information  Processing  Standards,  Information  Transfer  Standards, 
Information  Standards,  Marine-Machine  Interfaces,  and  Minimum  Desktop  Computer 
Configuration  and  Software  Product  Requirements. 
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COMMON  INTERFACE  "LANGUAGE' 


Mission 

Planning  Systems 


Intelligence  and 


Command  Center 
Systems 

T 


Logistics  and 
Admin  Systems 


Modeling  and 


Vioclellng 

Simulaii 


1  EW  Systems  |  - 

- 1  Systems  j 

Sensor  and 
Weapons  Systems 

DATABASE  ARCHITECTURE 

*  Standardized  Data  Elements 
(includes  MTFs  and  TADILs) 

►  Normalized  Logical  Structure 

►  Designated  Authoritative  Sources 


INTEGRATED  DATABASES 

•  Interoperable  warfare  sjstems 

•  Improved  reaction  times 

•  Command  and  Control  facilitated  by 
deconfiicted  information  exchange  * 

•  No  unnecessary  duplication  of  effort 

INTEROPERABLE  FUNCTIONAL  DATABASES 


Figure  12.  Objective  C4I  Database  Architecture  [From  Ref.  15] 


3.  System 

The  Navy  and  Marine  Corps  use  systems  architectures  as  descriptions,  including 
graphics,  of  systems  and  interconnections  providing  for  or  supporting  warfighting 
functions. 
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D.  CONCLUSION 


Copernicus,  the  Navy  and  Marine  Corps  strategy  to  achieve  joint  C4I 
interoperability,  is  fielded  and  operational,  but  is  continually  evolving.  Recently,  key 
agencies  from  the  Navy  and  Marine  Corps  met  to  focus  Copernicus  efforts  toward 
improving  support  for  the  Navy  and  Marine  team.  By  leveraging  commercial  technology 
and  following  simple  rules  for  C4I  development,  interoperability  will  be  achieved  and 
will  lower  the  cost  of  information  by  optimizing  a  system’s  ability  to  reach  more  users. 
[Ref.  16] 
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V.  ANALYSIS 


A.  INTRODUCTION 

The  previous  chapters  introduced  and  provided  a  broad  knowledge  base  of  both 
DoD  and  service  actions  to  achieve  joint  C4I  system  interoperability.  Chapter  V  builds  on 
this  to  conduct  a  consolidated  analysis  of  the  entire  action  spectrum.  Five  examples  are 
presented  to  illustrate  that  all  C4I  systems  are  not  the  same— each  system  has  its  own 
unique  functional  characteristics,  and  mission-specific  qualities  are  identified. 

This  chapter  contains  the  following  sections:  consolidated  initiative  summary, 
similarities  and  differences,  positive  actions,  further  definition,  mission-specific 
examples,  and  summary.  The  consolidated  initiative  summary  section  presents  a  vision, 
action,  and  baseline  action  matrix  to  analyze  DoD  and  service  initiatives.  The  similarities 
and  differences  and  positive  actions  sections  provide  comments  based  on  the  consolidated 
analysis,  while  the  further  definition  section  identifies  areas  requiring  additional 
development.  Within  the  mission-specific  examples  section,  five  C4I  systems  that  require 
extremely  different  functional  parameters  to  support  mission  objectives  are  presented. 
Each  example  system  subsection  is  divided  into  scenario,  objective,  mission  analysis,  and 
conclusions,  and  examples  are  further  compared  using  a  mission-specific  area  matrix. 
Finally,  a  summary  section  highlights  the  analysis  observations. 

B.  CONSOLIDATED  INITIATIVE  SUMMARY 

After  reviewing  the  Joint  Staff  s  C4IFTW  documents,  a  general  list  of  actions  to 
achieve  interoperability  was  prepared  to  compare  DoD  and  service  initiatives  to  ensure 
interoperability.  From  this,  a  consolidated  initiative  matrix.  Table  2,  was  developed  to 
compare  service  vision  and  implementation  documents.  Table  2  is  divided  into  three 
major  sections:  vision,  actions,  and  baseline  actions  (today).  The  vision  identified  within 
the  C4IFTW  concept  is: 
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•  Achieve  global  C4I  joint  interoperability, 

•  That  will  allow  any  Warrior  to  perform  any  mission— anytime,  any  place, 

•  That  is  responsive,  reliable,  secure,  and 

•  That  is  affordable.  [Ref  1] 

In  Table  2,  the  vision  section  denotes  the  key  documents  that  provide  each 
service’s  vision  to  achieve  interoperability.  The  actions  section  contains  explicit  tasks 
outlined  in  the  C4IFTW  vision  that  must  occur  to  attain  this  goal.  Most  of  these  actions 
are  Mid-term  Phase  actions  as  outlined  by  the  C4IFTW  roadmap.  Documents  identified 
are  not  all-inclusive,  but  the  list  provides  starting  points  that  formalize  system 
development  to  pursue  interoperability.  Finally,  the  baseline  actions  section  contains 
publications  and  tools  that  are  used  by  C4I  system  plarmers,  designers,  and  developers 
today. 

As  noted  from  the  publication  dates,  the  efforts  to  reach  interoperability  are 
continually  evolving.  The  actual  content  from  the  publications  provided  may  have  the 
same  purpose,  but  there  are  different  objectives  to  meet  individual  service  needs  and 
expectations. 

C.  SIMILARITIES  AND  DIFFERENCES 

As  identified  in  Table  2,  there  are  some  similarities  and  differences  between  DoD 
and  service  actions.  Even  though  this  table  provides  differences  from  service-to-service, 
readers  must  address  the  specific  content  of  these  documents  to  identify  the  actual 
similarities  and  differences  for  each  service. 

Every  service  has  a  vision,  and  each  vision  is  tailored  to  support  individual 
service  needs  and  expectations.  For  example,  the  Army  is  the  lead  service  with  respect  to 
the  definition  and  development  of  technical  architectures,  while  the  Air  Force  has  much 
success  with  employment  of  paperless  information  sharing  and  TRCs  via  the  WWW. 


34 


Consolidated  Initiative  Matrix  POD  USAF  |  USA  |  USN/USMC 


Copernicu 

Copernicu 

DOD  TAFI 
MCTA 

evolving 

DOD  TAFI] 
DDDS 

NWTDB/MC 

DOD  TAFI] 
MCTA 

DOD  TAFI] 
MCTA 

DOD  TAFI] 
MCTA 

DOD  TAFI] 
MCTA 

Q> 

Q> 

is 

is 

s 

s 

g 

s 

Vi 

Vi 

1— 1 

IV 

Cld 

1 — 1 

1 — t 

1 — 1 

1 — 1 

U 

a. 

5-1 

a 

s 

'^p< 

§c 

t-> 

Q> 

-U 

C 

S-l 

a> 

-*j 

C 

Q  ^ 

M 

o 

> 

Q  Q  ^ 

P 

P  ^ 

P  ^ 

H  H 

P  ^ 

W 

Pd 

P 

(p 

P 

O 

O 

o 

O 

Q 

P 

;p 

P 

p 

Q 

s 

s 

s 

S 

s 

1— 1 

» — 1 

1 — 1 

h-« 

)— t 

P  CQ  w 

p  w 

P 

P  w 

P  Vi 

S  P  ^ 

<!  o 

§  ^ 

<  o 

5  o 

Q  g 

^  P 

H  p:^ 

H  0^ 

H 

Q  Q  E-' 

P 

P  ^ 

Q  ^ 

Q  ^ 

O 

o 

O 

O 

O 

Q 

p 

P 

ip 

Q 

>^3  00  9 
S  o  o  . 

OrJ  nn  ' 

s  s  ^ 


s 

s 

s 

s 

1^0 

f_i 

1 — 1 

( — 1 

E-i  H  Q 

H 

H  H 

P  P 

P 

P 

P 

P 

O 

O 

O 

o 

O 

P 

Q 

P 

p 

P 

O)  ^  ’73 

I 

w  U5  W 
Cfl  -iH 


S-g  .1 
£  a  a 

a  rt^  § 

S  V, 

c;  cti  ^ 


Id  o  w 

W  ^-1  ^ 

dJ  cj 

^  c  erf 

-5  jc 


, - 1  V4 

(U  dl  O 

c  ^  ^ 

^  c  <i> 

§  c  c 

h  ®  '-»-4 

c  ^  O 

i 

"  C  O 

ra  0)  ^ 

X  £  -s 


"§-1 J 

Cl,  .y  *5  • 
o  w 
^  erf  J!> 
"q  ^ 

J-i  Cl  ^ 

erf  C 

a  .  s 

O  0*  ^ 

^  r— I 
<P  ^  ®  1 

■S  s 

^  o  ^ 
C  &  .2 

'TJ  erf  ^ 

*i>  s 

-T?'  « 

j-i  a>  ^  ' 

erf  .S 

'T?  cd  ^ 

C 

erf  S 

w  3  G 
0)  ^ 
I  2  £ 

^  a  g 

>  o  o 
<P  o 


w  tn  Ci,  f 

5->  erf  P 


^  ^  -o 

O  2 
o  -— I  lid 
C  QD  tH 

<p  c 
tlD  c  ^ 


■«  >  E 


35 


9£ 


p3nuijuo3  'z  aiqBX 


<d 

Ho 

Q 


< 

8^ 

Q 


^  <3 

p  < 

O 

Q 


Q 


H  H 

« 

O 

P 


oS 

-d 

r 

H  £ 

w  § 
A 

.2  OJ 

< 

d) 

S3  ^ 
;:3  'TJ 
0)  < 
n 
A 

PQ  • 


,  <3 

P  ^ 
O 


^  6 

8" 

P 


8^ 

P 


^  <3 

P  ^ 

O 

P 


P  ^ 

o 

p 


Hg 

P  ^ 

o 

p 


E-t  H 

P 

o 

Q 


P  ^ 
O 

p 


<3  p 
S  P 

^  P 


00 

•^O 

^  QJ^  H  > 
o  O  ^ 

-i 


Q 

S  ^  . 


^  B  g' 

H  <2  ^  , 

3  c:  o  : 


B  -2  •” 


§  “ 

a  ^  . 

o  a  in 

^  (u  a> 

5  I  & 


Q  S' 
•3  »'g 
569 
2  -S  “  • 

£  p’l  b  ■ 

gi  03  B  ' 

i 

1 13  'g 


!  S  2  ' 
5 


•tJ  S  0)  ( 


Cob 


^  13 
J  c  t  .2 
r  5  "3  S 


12  . 

>  £4  S  b 

^■•S  a  -3 

>  •-3  O 


P.5  .a 
o  CS 

^  u 
C  •  •  4> 

►S  10  t- 

W 

o  ^  S2, 

fc  °  O 

I  a 
Zx.B 
s  .S  ^  ^ 


Q 

O 

Q 


o  aS 
S  g  °  § 

■-D  .-3  4.  .S 


ga 


a  ;=i  -b 


a d  o 

£J  -3  <  o 

,  ^  rf  fe 

-  w  p  cu  ^ 


1  ^ 
^  g- 

13  £2 


i 

0)  w  m 

ftOi  t-H 

S  ^  « 

S  1^  VC 
ij  .a  N 
M  -  53 

^  tA  ^ 


^ggi3^3-a^^^ 


ij  ^  ij  o 

w  n  b  -3 

^03  c  03  ^  ^ 

■c  o  -c  .  b  S 

O  O  O  <  H 


00(0  b  (o 

(U  0)  -2  lU 

•  S  2  U  > 


Fh  H 

s  a 


Q  g*'^  g 
O  o  CO  ^ 

Q  O  U  Q 


J  O 
QT^ 

<c  < 


t,  Eli 

(4  ^  I 

ia ! 


.  Q  Q 
i  Q  O 
I  Q  Q 


Q 

Q 

O 

Q 


DOD  Instruction  4630.8  Procedures  for  Compatibility,  Interoperability,  and  Mod  &  Sim  Modeling  and  Simulation 

Integration  of  C3I  Systems,  18  Nov  92.  NWTDB  Naval  Warfare  Tactical  Database 

DOD  Reg  5000. 2-R  Mandatory  Procedures  for  Major  Defense  Standards  Manual,  Version  2.0,  Apr  94, 


D.  POSITIVE  ACTIONS 


Now  that  all  services  have  a  centralized  focus  and  vision  for  interoperability,  C4I 
system  development  promotes  seamless  interfaces  that  support  the  warfighter’s  needs.  As 
the  basic  building  blocks  for  automated  systems,  standard  data  elements  are  essential  for 
interoperability.  Without  a  centralized  starting  point,  efforts  would  be  useless. 
Additionally,  through  modeling  and  simulation  (M  &  S)  techniques,  C4I  system 
designers  and  developers  refine  system  parameters  to  ensure  interoperability,  which 
clearly  assist  with  the  definition  of  C4I  systems.  Even  though  the  Air  Force  does  not  have 
a  technical  architecture  to  guide  system  development,  they  provide  an  exceptional  on¬ 
line,  up-to-date  system  development  information  source  with  TRCs.  The  ability  to  access 
existing  standards  in  near  real-time  is  invaluable  to  C4I  system  development. 

E.  FURTHER  DEFINITION 

Even  with  a  centralized  focus  and  vision  for  interoperability,  there  are  several 
areas  that  must  be  further  defined  to  streamline  the  development  process:  the  definition  of 
interoperability  is  mission-specific,  existing  standards  (e.g.,  TAFIM)  are  too  large  and 
lack  consistency  [Ref  8],  and  there  is  no  formal  process  to  develop  interoperable  systems 
from  the  DoD  interrelated  set  of  architectures.  Depending  on  the  mission  purpose  of  a 
C4I  system,  individual  functional  characteristics  may  differ.  Systems  support  the 
Warfighter  and  command  and  control  functions,  but  interoperability  is  not  always  the 
same.  For  example,  systems  passing  imagery  in  near  real-time  are  not  designed  to  pass 
information  or  data  that  is  essential  to  counter  a  real-time  threat,  such  as  incoming  enemy 
aircraft.  The  detail  of  interoperability  must  be  defined  from  a  C4I  system’s  functional 
mission. 

Existing  development  standards  have  grovra  too  large  for  quality  management. 
Using  a  paperless  information  sharing  environment,  as  employed  by  the  Air  Force  with 
TRCs,  will  make  usable  standards  more  accessible  to  planners,  developers,  and  designers. 
The  organization  and  format  of  TRCs  provides  clear  guidance  for  system  development. 
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Now  that  the  DoD  has  defined  a  set  of  interrelated  architectures,  a  process  must  be 
developed  to  use  these  tools  to  build  interoperable  systems.  Currently,  key  people, 
systems  engineers,  etc.,  must  continually  be  involved  and  formally  track  system  design 
considerations  to  maintain  interoperability.  Inter-connectivity  is  as  important  as  intra¬ 
connectivity  for  all  C4I  systems. 

F.  MISSION-SPECIFIC  EXAMPLES 

After  recognizing  that  interoperability  is  mission-specific,  identifying  common 
parameters  with  different  characteristics  or  values  becomes  more  apparent.  The  following 
examples  provide  individual  mission-specific  profiles.  From  these  examples,  a  mission- 
specific  matrix  is  developed  to  demonstrate  that  there  are  quantitative  differences  for  each 
system. 

1.  Joint  Air  Defense  Mission  Profile 
a.  Scenario 

Joint  air  defense  consists  of  some  combination  of  Army,  Navy,  Air  Force 
and  Marine  systems  working  together  to  detect,  track,  identify,  engage,  and  kill  hostile  air 
threats.  ASCIET  95  (All  Service  Combat  Identification  Evaluation  Team)  tests  at 
Gulfport,  Mississippi,  during  September  1995,  serve  as  an  example  of  a  joint  air  defense 
mission.  The  purpose  of  the  ASCIET  95  program  was  to  examine  current  multi-service 
combat  identification  (CID)  procedures  and  capabilities  on  the  battlefield  and  to  identify 
necessary  changes  to  systems  interoperability,  doctrine,  and  tactics,  techniques  and 
procedures  (TTP).  [Ref  17] 

Figure  13  shows  a  schematic  view  of  the  ASCIET  95  scenario.  The  joint 
air  defense  system  consisted  of  Navy  Aegis  cruisers  stationed  in  the  Gulf  off  of  Gulfport; 
Army  PATRIOT  batteries  stationed  near  Gulfport;  a  variety  of  aircraft  overhead 
including  an  Air  Force  AWACS  and  RC-135,  and  Navy  E-2s  and  a  EP-3;  and  Marine 
close-in  air  defense  systems  including  HAWK,  Low  Altitude  Air  Defense 
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(LAAD)/Forward  Area  Air  Defense  (FAAD)  at  Camp  Shelby,  approximately  50  miles 
north  of  Gulfport.  [Ref.  1 7] 


AFrcraft  frrackir®&© 


OPFOR  STRIKER 

routing 


AEGIS 


AEGIS 


Figure  13.  ASCIET95  Scenario  [From  Ref.  17] 

During  exercises,  red  opposition  aircraft  flew  strike  routes  from  Eglin 
AFB  over  the  Gulf,  then  into  Gulfport  and  Camp  Shelby.  Besides  the  assets  mentioned 
above,  the  blue  forces  included  intercept  aircraft  on  CAP  over  the  Gulf.  The  pmpose  of 
the  exercises  was  to  use  the  joint  assets  to  detect,  track,  identify,  and  successfully  engage 
the  opposition  force  without  incurring  fratricide.  [Ref.  1 7] 

b.  Mission  Objective 

The  objective  of  the  joint  air  defense  mission  was  to  maximize  the 
probability  of  kill  of  all  hostile  air  targets  through  the  utilization  of  joint  assets,  while 
minimizing  the  loss  of  blue  force  assets  due  to  enemy  and  friendly  fire.  [Ref.  17] 
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c. 


Mission  Analysis 


A  generic  ASCIET95  C3I  information  flow  diagram  is  shown  in  Figure 
14.  The  challenges  are  to  provide  timely  connectivity  between  all  multi-service  C3I 
players  and  to  effectively  use  ID  and  track  information  to  support  joint  air  defense 
operations. 


Figure  14.  ASCIET95  Information  Flow  [From  Ref.  17] 

In  ASCIET95,  the  ID  coordinator  shown  in  Figure  14  was  the  Combat 
Identification  Coordinator  (CIDC)  and  the  decision  maker  was  the  Regional  Air  Defense 
Commander  (RADC).  In  addition  an  Interface  Control  Officer  (ICO)  had  a  key 
responsibility  for  providing  a  cormectivity  and  data  link  picture  to  the  RADC.  [Ref  17] 

Joint  air  defense  operations  (JADO)  control  responsibilities  were 
decentralized  to  an  assigned  regional  air  defense  commander  (RADC)  who  exercised 
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overall  command  and  control  of  all  participating  joint  air  defense  forces.  The  RADC 
could  divide  the  exercise  airspace  further  into  sectors  (i.e.,  overwater/overland)  and 
delegate  JADO  control  responsibilities  to  a  designated  sector  anti-air  warfare  commander. 
The  purpose  of  designating  a  RADC  was  to  minimize  the  overall  number  of  independent 
decision  makers  within  a  given  theater  of  operations,  provide  a  centralized  focal  point  for 
communications  connectivity,  and  reduce  the  time  for  target  ID-to-allocation-to- 
destruction  process.  [Ref  1 7] 

The  Aegis,  E-2,  TAOC,  and  E-3  functioned  as  the  RADC  at  various  times 
during  ASCIET95  and  provided  final  ID,  allocation  and  engagement  authority.  [Ref  1 7] 
The  CIDC  received  ID  data  from  various  ID  sources/providers  and  associated  it  with 
other  track  data  to  determine  the  correct  ID.  The  CIDC  then  recommended  that  ID  to  the 
RADC.  During  ASCIET  95,  Aegis,  RC-135,  EP-3  and  the  E-2C  functioned  as  the  CIDC 
to  resolve  probable  ID  recommendations  from  the  other  CID  systems.  [Ref  17] 

All  of  the  units  participating  as  RADCs,  CIDCs,  ICOs,  and  shooters  in 
ASCIET95  had  to  be  linked  by  a  communications  network.  There  are  a  variety  of 
communications  links  used  by  individual  units,  but  no  single  link  is  common  to  all  of  the 
units.  A  communications  architecture  used  in  ASCIET95  that  interfaces  the  various  links 
is  shown  on  Figure  15. 

During  ASCIET95,  it  was  observed  that  the  effectiveness  of  the  air 
defense  system  strongly  depended  on  the  time  latency  of  data  reaching  the  CIDC  and  then 
the  RADC.  The  system  began  to  lose  ability  to  correlate  data  as  information  was  delayed 
reaching  the  CIDC.  As  a  result,  multiple  tracks  of  the  same  air  vehicle  were  displayed 
and  target  IDs  were  miscorrelated  with  target  tracks.  In  some  cases  when  there  were 
approximately  70  actual  air  vehicles  (both  blue  and  red  combatants  and  background 
commercial  air  traffic)  in  the  battle  space,  there  were  approximately  200  unique  tracks 
being  reported  to  the  CIDC.  This  caused  long  differential  delays  of  information  coming 
from  separate  nodes  as  well  as  long  overall  delays  of  information  coming  from  single 
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nodes,  resulting  in  track  reports  of  the  same  target  from  different  reporting  nodes  falling 
outside  of  correlation  windows.  [Ref.  1 7] 


c;^ 

AEGIS*  ) 


Figure  15,  ASCIET95  Communications  Architecture  [From  Ref.  17] 


Delays  were  due  to  two  factors:  1)  disparities  in  communications  systems’ 
bandwidths  and  delays  at  network  translators  led  to  bottlenecks  in  the  flow  of 
information;  and  2)  multiple  nodes  reporting  the  same  information  led  to  an  overload  of 
the  tactical  networks  and  resulted  in  long  network  cycle  times.  Differential  delays 
between  JTIDS  and  TADIL-A  sources  of  information  were  reduced  as  message  loading 
was  reduced.  Similarly,  differential  delays  between  sources  of  information  from  different 
nodes  within  the  same  JTIDS  net  and  different  nodes  within  the  same  TADIL-A  net  were 
reduced  as  a  function  of  message  loading.  Thus,  as  illustrated  in  Figure  16,  network 
loading  and  the  control  of  the  amount  of  information  on  a  joint  air  defense  system 
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network  had  an  important  effect  on  the  ability  of  the  system  to  successfully  meet  the  joint 
air  defense  mission  objective.  [Ref  17] 


Time  Delay 


Figure  16.  Number  of  Messages  vs.  Time  Delay  [Ref.  17] 

d.  Conclusions 

Analysis  of  ASCIET95  indicates  that  all  of  interoperability  requirements 
specified  in  the  consolidated  initiative  matrix.  Table  2,  were  met.  All  systems  were  linked 
using  interoperable  communications  links  and  translators.  Common  message  formats 
were  used.  However,  there  were  additional  mission-speeifie  requirements  that  were  not 
identified  prior  to  condueting  ASC1ET95.  These  included  maximum  time  delays  in 
information  reaching  the  combat  ID  coordinator,  maximum  differential  delays  in 
information  being  reported  on  the  same  target  by  different  nodes,  and  a  maximum 
network  loading  that  depended  on  the  particular  network  type. 

Current  interoperability  guidelines  say  that  this  type  of  additional  mission- 
specific  requirement  will  be  identified  during  analysis  of  mission  interoperability 
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requirements.  However,  these  types  of  interoperability  requirements  can  often  only  be 
discovered  at  the  joint  mission  analysis  level.  Service-specific  systems  developed  for 
service-specific  missions  may  not  be  fully  interoperable  for  joint  missions  if  joint  mission 
requirements  have  not  been  completely  analyzed  by  the  developing  service.  Therefore, 
there  is  a  need  to  look  at  potential  joint  mission  applications  of  individual  service  system 
developments  and  derive  the  necessary  additional  interoperability  requirements  arising 
from  joint  applications. 

Also,  in  the  case  of  ASCIET95,  there  was  an  identified  need  to  provide 
network  control  at  the  system  level  in  order  to  reduce  network  delays.  The  requirement 
for  network  control  at  this  level  is  a  joint  requirement  and  leads  to  the  need  for  new 
hardware  and/or  software  that  is  not  a  service-specific  development  item  but  is  a  joint 
development  item.  This  identifies  the  need  to  have  a  joint  service  systems  engineering 
organization  responsible  for  some  subset  of  interoperability  issues. 

2.  Joint  Tactical  Ballistic  Missile  Defense  Mission  Profile 

a.  Scenario 

An  example  of  a  joint  tactical  ballistic  missile  (TBM)  defense  scenario  is 
shown  in  Figure  17.  Here  we  have  assumed  a  littoral  environment  typical  of  a  Korean 
theater.  Army  Theater  High  Altitude  Air  Defense  (THAAD)  and  Patriot  batteries  are 
stationed  on  the  land  area.  Future  Aegis-based  mid-tier  missile  defense  systems  are 
offshore.  An  Air  Force  future  airborne  laser  (ABL)  is  overhead.  The  ABL  will  be  capable 
of  detecting,  tracking,  engaging,  and  killing  TBMs  during  their  boost  phase  at  long  stand¬ 
off  ranges,  up  to  500  miles.  THAAD  and  Aegis  systems  are  mid-tier  systems,  capable  of 
detecting,  tracking,  engaging,  and  killing  TBMs  during  midcourse,  after  booster  burnout 
and  separation.  PATRIOT  is  a  lower  tier  defense  system,  capable  of  defending  point 
targets  and  small  areas.  [Ref  18] 
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Air  Defense 


Boost  Phase  Intercept 


Destruction  of  Launchers 


Figure  17.  Joint  Tactical  Ballistic  Missile  Defense  Scenario 


b.  Mission  Objective 

The  objective  of  a  joint  tactical  ballistic  missile  defense  mission  is  to 
detect,  track,  engage,  and  perform  complete  raid  attrition  of  the  missile  attack  with  the 
most  efficient  application  of  joint  detection,  tracking,  and  firepower  capabilities.  [Ref 
18] 

c.  Mission  Analysis 

Figure  17  shows  a  schematic  of  a  tactical  ballistic  missile  flight,  from 
launch  to  impact,  as  well  as  the  approximate  intercept  regions  of  ABL,  THAAD,  AEGIS, 
and  PATRIOT. 

ABL  uses  an  infrared  surveillance  system  and  will  detect  a  missile  launch 
as  soon  as  the  missile  breaks  cloud  top,  approximately  40  seconds  after  launch  for  high 
cloud  cover,  or  immediately  upon  launch  in  clear  skies.  ABL  can  rapidly  develop  a  high 
accuracy  track  of  the  missile  due  to  the  high  resolution  and  measurement  accuracy  of  the 
electro-optical  surveillance  system.  ABL  can  then  engage  and  kill  missiles  during  the 
boost  phase,  but  since  kill  times  using  the  directed  energy  weapon  are  on  the  order  of  5- 
1 0  seconds  ABL  can  only  engage  a  subset  of  a  large  missile  attack.  [Ref.  1 8] 
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THAAD  and  AEGIS  both  perform  exoatmospheric  engagements  on 
incoming  missiles.  Detection  and  tracking  is  performed  by  the  THAAD  ground-based 
radars  and  the  AEGIS  SPY  radars,  respectively.  These  radars  detect  targets  after  launch, 
at  the  radar  horizon  if  they  are  looking  in  the  proper  area,  and  detection  ranges  are 
typically  several  hundred  miles.  The  radars  can  be  cued  by  ABE  or  by  space-based 
sensors  in  order  to  focus  their  radar  energy  in  a  narrow  beam  that  allows  earlier  detection 
of  targets  in  some  situations.  Both  systems  develop  fire  control  quality  data  for  their  own 
weapons.  The  AEGIS  system  might  also  incorporate  the  cooperative  engagement 
capability  (CEC)  system  which  sends  fire-control-quality  track  data  from  any  CEC 
platform  to  all  other  CEC  platforms.  All  CEC  equipped  platforms  have  the  same  set  of 
radar  processing  software  and  hardware,  and  all  CEC  radars  are  gridlocked  to  high 
accuracy,  resulting  in  all  CEC  platforms  having  identical  track  pictures.  All  CEC  systems 
must  be  linked  by  a  high  (2-10  MHz)  bandwidth  system  to  allow  data  transfer  and 
sensor  gridlocking.  PATRIOT  detects,  tracks,  and  engages  leakers  in  the  lower  tier. 
PATRIOT  can  be  cued  by  track  data  from  THAAD  and  AEGIS.  [Ref  18] 

There  are  several  interoperability  issues  that  must  be  addressed  in  order  to 
coordinate  the  system  and  achieve  optimal  joint  performance.  These  issues  are  related  to 
three  levels  of  coordinated  activity.  First,  the  systems  would  have  to  be  linked  via 
communications  systems  in  near  real-time  in  order  to  provide  cueing  from  tier  to  tier. 
Second,  the  systems  would  have  to  be  linked  via  communications  systems  in  real  time  or 
near  real  time  in  order  to  relay  information  concerning  which  targets  have  been  engaged 
or  are  planned  to  be  engaged,  and  which  targets  have  been  killed  or  failed  to  be  killed. 
Failing  to  do  this  will  result  in  multiple  shots  at  the  same  target,  leakers  that  are  not 
engaged  by  any  system,  and  extraneous  track  information  due  to  unidentified  interceptor 
missiles  in-flight.  Third,  the  systems  could  be  linked  in  real  time  in  such  a  way  that 
would  allow  the  theater  battle  management  to  be  coordinated  jointly,  rather  than  relying 
on  areas  of  responsibility.  The  advantage  of  joint  battle  management  is  that  it  allows 
optimal  joint  system  performance  provided  information  flow  timelines  can  be  met.  Joint 
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battle  management  requires  that  all  systems  be  linked  via  a  communications  system  in 
real  time;  if  CEC  is  to  be  used  theater-wide  then  the  communications  system  must  be 
high  bandwidth.  Each  participating  system  must  have  a  battle  management  software 
system  that  is  interoperable  with  all  other  system  battle  management  software  systems  in 
terms  of  message  formats,  data  elements,  data  accuracies  and  update  rates;  in  terms  of 
modularity  of  function  (each  individual  system  must  be  able  to  operate  as  a  node  in  a 
distributed  battle  management  system);  and  in  terms  of  shared  system  information.  The 
latter  refers  to  the  need  to  know  exact  details  of  every  system’s  state,  including  magazine 
state,  in  order  to  determine  optimum  distributed  firing  allocations.  The  requirements 
associated  with  these  three  levels  of  coordinated  operation  are  listed  in  Table  3.  [Ref  18] 

d.  Conclusions 

Analysis  of  the  example  joint  tactical  ballistic  missile  defense  mission 
indicates  that  all  of  the  interoperability  requirements  specified  in  Table  2  apply.  All 
systems  need  to  be  linked  using  interoperable  communications  links  and  translators. 
Common  message  formats  need  to  be  used.  However,  there  were  additional  mission- 
specific  requirements  that  are  not  identified  in  Table  2.  These  include  the  need  for  real¬ 
time  or  near-real-time  communications  links  so  that  maximum  time  delays  in  information 
reaching  the  various  missile  defense  tiers  is  short  enough  to  allow  the  required  action  by 
each  tier.  There  is  a  need  to  transmit  information  that  is  internal  to  each  of  the  systems  to 
all  other  systems.  This  requires  that  the  systems  be  designed  such  that  there  are  real  time 
transmittals  of  the  internal  information  to  external  systems,  and  that  the  information  is  in 
a  common  format.  Finally,  level  3  of  coordinated  action  requires  that  the  internal 
functioning  of  the  systems  be  designed  such  that  battle  management  can  be  performed 
externally  to  each  system  as  well  as  internally.  Level  3  coordination  also  requires 
development  of  a  joint  battle  management  system  with  all  of  the  interoperability 
requirements  listed  in  Table  3. 
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Requirement 

Level  1 
Cueing 

Level  2 

Shared  Engagement  Data 

Level  3 

Joint  Battle  Management 

Comm  Links 

Near  real-time 

X 

X 

X 

Real-time 

or  X 

X 

High  bandwidth, 
real-time 

X  (with  CEC) 

Shared  Data 

Engagements 

X 

X 

Kill  assessment 

X 

X 

Tracks 

X 

X 

Sensor  data 

X  (with  CEC,  excluding 
ABL) 

System  state  data 

X 

Battle  Management  System 

Common  software 
modularity 

X 

Common  data 
dictionaries 

X 

Table  3.  Derived  Interoperability  Requirements  for  Joint  Tactical  Ballistic  Missile 

Defense  [From  Ref.  18]. 

3.  Global  Positioning  System  Profile 


a.  Scenario 

The  application  of  Global  Positioning  System  (GPS)  technology  has 
increased  the  operational  effectiveness  of  the  armed  forces.  Military  users  in  air,  on  land, 
and  at  sea  receive  accurate  navigational  information  to  guide  their  fighting  force  within 
every  environment.  GPS  technology  is  being  incorporated  within  networked  positioning 
systems  to  increase  the  navigational  accuracy  at  all  levels.  As  the  services  conduct  more 
joint  operations  and  training,  the  need  to  share  accurate  positioning  information  becomes 
essential  in  the  joint  battlespace  environment.  Ground  troops  from  one  service  may 
receive  support  from  both  air  and  sea  imits  of  another.  Figure  18  illustrates  an  operational 
example  where  Navy  aircraft  are  in  direct  support  of  Army  ground  troops. 
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GPS  Constellation 


Figure  18.  Joint  Battlespace  Scenario 


b.  Mission  Objective 

Within  this  proposed  operational  scenario,  there  is  no  established  means 
for  both  air  and  ground  forces  to  pass  navigational  and  positioning  information  or 
coordinate  operations.  The  lack  of  communications  connectivity  between  air  and  ground 
elements  is  not  only  limited,  but  extremely  dangerous  for  all  entities  involved.  Figure  19 
represents  a  proposed  operational  architecture  for  the  insertion  of  GPS  data  and 
establishment  of  critical  communications  links  between  air  and  ground  units. 

Both  air  and  ground  units  receive  accurate  positioning  information  from 
the  GPS  satellite  constellation.  As  air  and  ground  forces  come  within  some  predetermined 
range  of  each  other,  they  begin  to  exchange  positioning  information  through  a 
temporarily  established  communications  data  link. 
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GPS  Constellation 


Figure  19.  Proposed  Communications  Architecture 


c.  Mission  Analysis 

The  communications  data  link  must  be  established  early  enough  to  provide 
positioning  and  navigational  systems  the  time  to  process  the  information  received.  Also, 
force  elements  require  ample  time  to  observe,  recognize,  and  react  safely  in  support  of 
real-time  operations.  If  aircraft  navigational  systems  use  earth-centered  coordinates  and 
ground  force  positioning  systems  use  flat  earth  coordinates  for  operation,  systems  require 
design  parameters  to  perform  information  conversion  and  maintain  functionality  to 
support  timely  information  flow.  Predetermined  range  identification  distances  may  need 
to  be  increased  to  support  real-time  operations. 
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d. 


Conclusions 


Both  air  and  ground  unit  systems  must  use  standard  message  formats  and 
data  elements,  as  specified  in  Table  2.  The  timing  and  accuracy  of  navigational  data 
passed  over  a  communications  link  between  air  and  ground  assets  is  critical  for  C4I 
systems  of  this  type.  Information  must  be  timely  to  ensure  C4I  systems  successfully 
support  users  and  accurate  enough  to  clearly  represent  the  operational  environment.  The 
operational  field  of  view  greatly  differs  between  aircraft  and  ground  forces;  therefore, 
accurate  information  is  key  to  operational  awareness. 

4.  High  Altitude  Endurance  Unmanned  Aerial  Vehicle  Imagery  Data 

Link  Profile 

a.  Scenario 

With  lessons  learned  from  Operation  Desert  Storm,  the  DoD  found 
existing  deficiencies  in  military  Operations  Other  Than  War  (OOTW)  which  included  the 
following:  [Ref  19] 

•  Lack  of  broad  area  coverage 

•  Limited  Battle  Damage  Assessment  (BDA) 

•  Limited  imagery  dissemination  to  users 

•  Limited  information  retrieval  and  distribution  of  intelligence  data 

•  Insufficient  information  to  support  Warfighter  situational  awareness 

•  Insufficient  high  resolution  imagery  intelligence  to  support  precision  strikes 

•  Reconnaissance  that  is  not  synchronized  with  the  Warfighter 

The  goal  of  the  High  Altitude  Endurance  Unmanned  Aerial  Vehicle  (HAE 
UAV)  is  to  provide  quality  extended  reconnaissance  that  is  responsive  to  the  operational 
Warfighters’  needs.  [Ref  19] 
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b. 


Mission  Objective 


The  HAE  UAV  system  is  designed  to  provide  near  real-time  (NRT) 
transmission  of  sensor  imagery.  The  HAE  UAV  is  a  long  dwell  tactical  surveillance  and 
reconnaissance  system  that  is  capable  of  sustained  high  altitude  operations  over  and  into 
high  threat  areas.  The  system  can  operate  at  ranges  in  excess  of  500  nautical  miles  from 
the  launch  area  and  loiter  over  the  target  area  more  than  eight  hours  at  an  altitude  greater 
than  45,000  feet.  The  HAE  UAV  employs  both  wideband  line-of-sight  (LOS)  and 
moderate  bandwidth  satellite  communications.  [Ref  19] 

The  HAE  UAV  system  contains  a  ground  segment  (mission  control 
element  (MCE)),  ground  communications  element,  launch  and  recovery  element  (ERE)), 
and  support  segment,  which  can  be  mission  transportable  to  any  theater  of  operations  via 
three  C-141  aircraft  or  equivalent  loads.  [Ref  19]  Figure  20  shows  an  operational  view  of 
the  HAE  UAV  system. 

The  system  is  designed  to  provide  24  hour  continuous  coverage  of  desired 
areas  of  interest  using  Synthetic  Aperture  Radar  (SAR),  Electro-Optic  (EO),  and  Infrared 
(IR)  sensors.  The  HAE  UAV  system  can  collect  imagery  of  pre-planned  areas  of  interest 
and  quickly  transmit  the  messages  to  combat  commanders.  [Ref  19] 

c.  Mission  Analysis 

Figure  20  illustrates  the  program  objective  for  using  a  satellite  link  for  the 
transmission  of  imagery  data  from  the  aircraft  to  the  MCE  and  selected  imagery  data 
from  the  aircraft  to  exploitation  sites  and  tactical  users.  Using  commercial  satellites,  data 
rates  up  to  50  Mbps  are  expected,  while  T-1  rates  are  anticipated  for  links  to  tactical 
elements.  Figure  21  illustrates  the  second  method  for  imagery  transmission  from  the 
aircraft  to  the  MCE,  exploitation  elements,  and  tactical  users.  Through  LOS  systems, 
aircraft  to  MCE  and  exploitation  elements  data  rates  will  increase  to  137  Mbps,  and  links 
to  tactical  users  will  remain  at  T-1.  [Ref.  19] 
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Figure  20.  In  Theater  Operational  HAE  UAV  System  using  Commercial  SATCOM 

(Ku  Band)  [From  Ref.  19] 
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Figure  21.  In  Theater  Operational  HAE  UAV  System  using  Common  LOS  Data 

Links  [From  Ref.  19] 
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Different  operational  parameters  change  C4I  system  development.  The  two 
communications  architecture  options,  illustrated  in  Figure  20  and  Figure  21,  create 
different  requirements  for  the  design  and  development  of  C4I  systems  to  support  both  the 
MCE  and  exploitation  elements — ^the  interoperable  designs  have  become  mission- 
specific. 

d.  Conclusions 

Since  the  LOS  link  from  the  aircraft  to  the  tactical  user  remains  the  same, 
the  development  of  the  tactical  users’  terminal  requires  no  apparent  change.  The  possible 
bandwidth  limitations  may  even  alter  the  operational  use  and  employment  of  the  system. 
New  dissemination  devices  may  have  to  be  designed  to  support  the  distribution  of 
imagery  to  the  user. 

5.  Close  Air  Support  Profile 

a.  Scenario 

Commanders  use  close  air  support  (CAS)  to  focus  firepower  at  the 
decisive  place  and  time  to  achieve  local  combat  superiority.  Figure  22  depicts  the  flow  of 
information  from  the  time  that  friendly  ground  forces  identify  an  enemy  threat  to  the 
delivery  of  munitions  on  the  target.  Requests  for  CAS  are  usually  on  high  frequency 
(HF),  ultra  high  frequency  (UHF),  and  very  high  frequency  (VFIF)  radio  voice  nets. 
Tactical  air  control  parties  (TACPs),  liaisons  to  ground  forces,  request  CAS  through  the 
direct  air  support  center  (DASC);  this  may  be  an  airborne  C2  platform.  By  monitoring  the 
Tactical  Air  Request  (TAR)  Net,  battalion,  regiment,  and  division  level  fire  support 
coordination  centers  (FSCCs)  approve  requests  by  remaining  silent  and  deny  or  alter 
requests  as  needed.  [Ref.  20] 

b.  Mission  Objective 

CAS  execution  must  be  responsive  to  quickly  support  forward  ground 
forces.  To  deter  the  fast-paced  threats  of  the  battlefield  and  to  lower  operational  risks, 
offensive  actions  require  immediate  support  to  counter  enemy  intentions. 
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Figure  22.  Information  Flow  for  Close  Air  Support  Requests 

c.  Mission  Analysis 

C4I  systems  must  be  flexible  to  support  tactical  users  at  multiple  locations 
throughout  the  battlefield.  The  delay  of  information  may  place  forces  at  risk.  Even  though 
CAS  requests  are  not  automated,  there  are  many  operational  and  design  tradeoffs  for  C4I 
systems  to  ensure  the  request  process  can  support  real-time  operations.  Radio  voice 
quality  must  be  understandable  for  users  to  quickly  identify  essential  information  without 
retransmission. 

d.  Conclusions 

As  defined  in  Table  2,  C4I  system  designs  with  common  standards  ensure  all  forces  have 
reliable  connectivity  to  conduct  operations  for  real-time  operations.  If  C4I  systems  do  not 
facilitate  CAS  operations,  the  ability  to  access  powerful  lethal  assets  becomes  limited. 
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High  voice  quality  for  systems  alleviates  the  need  for  retransmission.  If  the  request 
structure  required  data  links,  mission-specific  parameters  would  change  the  design  of  the 
C4I  system  to  achieve  adequate  interoperability. 

6.  Mission-Specific  Area  Matrix 

In  Table  4,  mission  profile  areas  are  compared  against  one  another  using  four  of 
seven  information  quality  criteria  identified  in  Joint  Publication  6-0.  These  criteria  are: 
[Ref  21] 

•  Accuracy.  Information  that  conveys  the  true  situation. 

•  Timeliness.  Information  that  is  available  in  time  to  make  decisions. 

•  Completeness.  All  necessary  information  required  by  the  decision  maker. 

•  Security.  Information  that  has  been  afforded  adequate  protection  where 
required. 

From  these  criteria,  an  interoperability  profile  can  be  created.  Each  area  is  given  a 
rating  of  high,  medium  (med),  or  low.  For  high,  the  C4I  system  attribute  is  essential  or 
extremely  relevant  to  support  warfighter  operations  in  real-time.  For  a  medium  rating,  the 
system  attribute  is  critical  or  relevant  to  support  operations  in  near  real-time  (NRT),  and 
low  is  important,  but  not  as  timely  as  NRT. 

Timeliness,  accuracy,  completeness,  and  security  criteria  for  a  C4I  system  can  be 
quantified  to  better  define  a  desired  system’s  requirements.  As  identified  in  Table  4,  there 
are  significant  differences  and  the  depth,  level,  detail,  etc.  of  interoperability  must  be 
defined  for  each  specific  case. 
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Mission  Profile  Areas 
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G.  SUMMARY 

The  DoD  and  services  have  initiated  extensive  visions  to  focus  service  efforts  and 
achieve  C4I  system  interoperability.  Service  actions  are  tailored  to  support  individual 
needs  and  requirements,  and  standards  are  clearly  defined  and  accessible  to  facilitate  joint 
C4I  interoperability  development  of  future  systems.  Technical  architectures  and  reference 
codes  provide  the  guidance  to  design  interoperable  systems,  but  every  system  is  not  the 
same.  Each  system  requires  systems  engineering  analysis  to  ensure  mission-specific 
parameters  are  met,  and  interoperability  is  more  than  seamless  interfaces.  In  addition  to 
timeliness,  data  and  information  may  require  different  accuracy,  completeness,  and 
security  levels  for  C4I  systems  to  be  functional.  As  noted  within  Table  2,  a  consolidated 
initiative  matrix,  every  service  has  defined  actions  to  achieve  interoperability,  but  as  the 
mission-specific  examples  of  this  chapter  have  demonstrated,  as  shovm  in  Table  4,  every 
case  is  different.  C4I  system  purposes,  missions,  operational  architectures,  etc.  affect 
system  parameters  that  ensure  interoperable  systems  are  functional. 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  term  interoperability  has  little  meaning  unless  specific  parameters 
are  described  and  specified... [Ref.  1] 

C4I  for  the  Warrior 
12  June  1992 

A.  INTRODUCTION 

Even  the  original  C4IFTW  document  identified  that  every  system  is  not  the  same, 
and  system  parameters  must  be  specified  in  detail.  Building  on  the  previous  five  chapters, 
this  chapter  identifies  critical  issues,  provides  direction,  and  recommends  research  areas 
requiring  analysis.  Chapter  VI  contains  the  following  sections:  conclusions, 
recommendations,  and  further  research.  The  conclusions  section  formalizes  analysis 
observations  identified,  and  the  recommendations  section  presents  three  initiatives  to 
enhance  the  development  of  joint  C4I  systems.  Finally,  the  further  research  section 
identifies  four  areas  of  study  for  DoD  graduate  students. 

B.  CONCLUSIONS 

The  definition  of  interoperability  specified  in  Joint  Publication  1-02  is  vague 
regarding  mission-specific  C4I  systems.  As  written,  the  definition  requires  the  users, 
developers,  planners,  designers,  etc.  to  further  define  interoperability  for  each  mission- 
specific  case.  Alone,  the  ability  to  pass  data  through  seamless  interfaces  does  not  ensure 
that  systems  receive  information  in  a  timely  manner  to  render  the  system  functional. 
Also,  incomplete  and  inaccurate  information  can  not  only  mislead,  but  slow  down  the 
warfighter’s  decision  making  process.  C4I  systems  must  be  designed  to  facilitate 
command  and  control  and  provide  a  well-defined  picture  of  the  battlespace  without 
confusion.  Interoperability  must  be  defined  for  the  system  frame  of  reference  and  the  use 
of  the  C4I  system. 
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c. 


RECOMMENDATIONS 


1.  C4I  System  Mission  Interoperability  Profiles 

As  identified  in  Joint  Publication  6-0,  information  flow  must  be  nearly 
instantaneous  both  vertically  and  horizontally  within  an  organizational  structure  [Ref 
21].  This  publication  further  describes  the  information  quality  criteria  listed  in  Table  5. 


Accuracy 

Information  that  conveys  the  true  situation 

Relevance 

Information  that  applies  to  the  mission,  task,  or  situation  at  hand 

Timeliness 

Information  that  is  available  in  time  to  make  decisions 

Usability 

Information  that  is  common,  easily  understood  format  and  displays 

Completeness 

All  necessary  information  required  by  the  decision  maker 

Brevity 

Information  that  has  only  the  level  of  detail  required 

Security 

Information  that  has  been  afforded  adequate  protection  where  required 

Table  5.  Information  Quality  Criteria  [From  Ref.  21] 


From  accuracy,  timeliness,  completeness,  and  security  information  quality 
criteria,  an  interoperability  profile  can  be  created.  These  criteria  or  attributes  for  a  C4I 
system  can  be  quantified  to  better  define  a  desired  system’s  requirements.  For  example,  a 
system  that  transports  essential  air  defense  information  must  be  more  accurate,  timely, 
and  complete  to  react  to  a  real-time  threat  than  a  system  that  passes  imagery.  This  is  a 
simplified  example,  but  consider  the  quantifiable  differences  for  each  item  of  criteria.  C4I 
systems  must  be  interoperable,  but  to  what  level?  If  an  air  defense  system  is  considered 
interoperable  and  accurately  passes  complete  information  both  vertically  and 
horizontally,  but  fails  to  pass  this  information  in  a  timely  manner,  then  the  system  is 
useless. 

Establishing  profiles  for  C4I  systems  will  further  define  and  describe  user 
requirements  and  assist  system  designers  and  developers  to  ensure  adequate  levels  of 
interoperability.  To  just  identify  interoperable  levels  provides  no  quantifiable 
characteristic  to  follow. 

Table  6  contains  a  proposed  framework  to  establish  C4I  system  profiles. 
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C4I  System 

Attribute 

Proposed  Definition 

Quantifiable 

Measure 

Accuracy 

Data  accuracy  that  conveys  the  true  situation 

percentage  or  Bit 

Error  Rate 

Timeliness 

Time  allocated  for  data  to  reach  a  C4I  system  so  it  may  be 
processed  in  time  to  render  the  system  effective 

measured  in  seconds 
or  milliseconds 

Completeness 

Data  amount  that  conveys  the  true  situation 

percentage 

Security 

Security  level  required  for  system  operation 

(e.  g,,  unclass, 
secret,  etc.) 

Table  6.  Proposed  Interoperability  Profiles 


Profiles  must  be  initially  established  as  C4I  system  requirements  are  defined  and 
optimized  through  modeling  and  simulation  and  joint  testing  processes.  The  overall 
purpose  of  mission-specific  profiles  is  not  to  create  unrealistic  requirements  and  delay  the 
development  process  for  C4I  systems,  but  to  establish  thresholds  to  guide  designers  from 
requirement  definition  through  initial  design,  modeling  and  simulation,  and  subsequent 
system  upgrades.  As  DoD  guidance  and  technology  advance,  profiles  should  be  updated 
to  better  support  interoperability  of  like  systems-they,  too,  are  continually  evolving. 

2.  Joint  Scenario  Testing 

DoD  Directive  4630.5,  Compatibility,  Interoperability,  and  Integration  of  C3I 
Systems,  states  that  all  C4I  systems  are  considered  joint  unless  exemptions  are  granted. 
As  indicated  by  the  ASCIET95  series  of  tests,  systems  must  be  modeled  and  simulated 
and  tested  in  joint  scenarios.  Interoperability  is  much  more  than  reliable  interfaces.  C4I 
systems  may  seamlessly  interface,  but  they  are  not  interoperable  if  the  traffic  load  from 
joint  and  service  specific  systems  creates  time  delays  rendering  the  overall  network  of 
systems  ineffective.  Joint  scenario  modeling  and  simulation  and  testing  is  essential  to 
ensure  interoperability  of  networked  systems. 

3.  On-line  Interoperability  Standards 

The  US  Air  Force’s  development  of  Technical  Reference  Codes  (TRCs)  has 
dramatically  enhanced  progress  to  achieve  interoperability  for  all  Air  Force  C4I  systems. 
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up-to-date  standards  and  system  development  information  can  be  quickly  accessed  to 
guide  system  planners,  developers,  and  designers  vvithin  the  Air  Force.  The  logical 
organization  of  TRC  development  standards  is  an  effective  tool  for  the  commercial 
industry  as  well  as  service  personnel.  As  long  as  TRCs  are  adequately  maintained,  the 
time  from  requirements  definition  to  placing  the  C4I  system  in  the  hands  of  the 
warfighter  will  be  reduced.  All  services  must  adopt  this  real-time  concept  of  operations. 

D.  FURTHER  RESEARCH 

1.  Further  Develop  C4I  System  Interoperability  Profiles 

From  today’s  proposed  interoperability  levels,  further  develop  C4I  system  profiles 
to  quantify  design  requirements  of  military  systems. 

2.  Model  a  System  Development  Process 

Using  commercial  industry  and  theoretical  automated  information  system 
development  techniques,  model  a  system  development  process  that  uses  the  DoD 
interrelated  set  of  architectures  as  the  starting  point. 

3.  Identify  Key  Data  Repository  Elements 

Compare  commercial  industry  and  military  automated  information  system 
development  techniques  to  identify  similarities  and  differences  and  key  data  repository 
elements  for  military  application. 

4.  Further  Develop  the  Copernicus. ..Forward  Vision 

Further  develop  the  Copernicus... Forward  vision  to  strengthen  the  US  Navy  and 
Marine  Corps  team  and  enhance  forward  presence  operations. 
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